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This  document  describes  the  SAM /SAL  system  implemented 
at  the  University  of  Colorado  during  19R0.  SAM  is  a  Static 
Analysis  Machine  with  a  Static  Analysis  Language,  SAL.  The 
main  purpose  of  SAM/ SAL  is  to  specify  arbitrary  programming 
languages  so  that  when  programs  in  the  specified  language 
are  run  through  the  SAM/SAL  system,  an  annotated  flowgraph 
representation  of  the  program  is  generated. 
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CHAPTER  1 


The  SAM/SAL  System 


1.1.  Introduction 


,_1  ._1 .  Purpose 

This  document  describes  the  SAM/ SAL  system  implemented 
at  the  University  of  Colorado  during  1980.  SAM,  an  acronym 
for  Static  Analysis  Machine,  is  the  current  name  given  to 
the  whole  system.  SAL,  an  acronym  for  Static  Analysis 
Language,  is  the  specification  language  provided  by  SAM 
through  which  most  of  SAM's  descriptive  capabilities  are 
manifested.  Since  SAL  is  such  an  integral  part  of  the 
overall  system,  the  system  will  often  be  referred  to  as 
SAM/ SAL. 

The  main  purpose  of  SAM/ SAL  is  to  provide  a  capability 
for  specif iying  arbitrary  programming  languages.  A  specifi¬ 
cation  is  to  be  aimed  at  generating  annotated  flowgraphs  for 
programs  written  in  the  specified  language.  An  annotation 
is  regarded  as  a  defined  action  occurring  to  a  set  of 
defined  objects.  As  an  example,  in  a  specification  of  the 
language  PASCAL,  the  user  might  want  the  PASCAL  statement 

X  :=  Y+Z 

to  generate  a  single  flowgraph  node  n  which  is  annotated 
with  the  action  REFERENCE  to  the  set  of  objects  {Y,Z}  and 
DEFINE  to  the  set  of  objects  { X } .  In  this  case,  the  user 
must  be  able  to  declare  X,  Y  and  Z  as  objects  of  some  class, 
declare  the  actions  DEFINE  and  REFERENCE  to  be  valid  on  sub¬ 
sets  of  objects  from  this  class,  and  specify  that  the 
assignment  statement  above  results  in  the  creation  of  a 
f 1 owg  raph  node . 

Figure  1.1  gives  a  graphic  description  of  how  SAM/ SAL 
works.  At  the  top  of  the  figure,  a  specification  program  S 
is  submitted  to  SAL  for  compilation.  Outputs  from  SAL  are 
then  fed  to  an  automatic  parser  generator  and  to  a  semantic 
evaluator  generator.  A  parser  and  semantic  evaluator  are 
then  produced.  A  typical  program  U  written  in  the  language 
specified  by  S  can  then  be  fed  to  the  generated  parser;  the 
parser  output  is  in  turn  fed  to  the  generated  semantic 
evaluator;  and  the  semantic  evaluator  in  turn  produces  the 
desired  annotated  flowgraphs  associated  with  the  program  U 
as  specified  by  S. 
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Two  output  files  are  generated  by  the  semantic  evalua¬ 
tor  . 

(1)  Listings  File. 

The  listings  file  contains  (a)  any  system  error  mes¬ 
sages  resulting  from  the  semantic  evaluation  phase,  (b) 
any  special  output  requested  by  the  user,  and  (c)  a 
listing  of  program  statistics. 

(2)  Tables  File. 

The  tables  file  is  automatically  generated  by  the 
semantic  evaluator  upon  successful  semantic  analysis  of 
the  input.  Primarily,  this  file  contains  a  dump  of  the 
symbol  table,  callgraph  and  flowgraphs  generated  by  the 
semantic  evaluator  for  the  input . 

Details  on  how  this  system  works  on  the  CU  CDC-Cyber 
system  are  given  in  Appendix  A. 

1_._1. 2.  Motivation 

Research  directed  by  Drs.  Leon  J.  Osterweil  and  Lloyd 
D.  Fosdick  has  lead  to  the  design  and  implementation  of  a 
software  tool,  DAVE,  which  automatically  detects  certain 
static-semantic  and  data-flow  errors  in  ANSI  Standard  For¬ 
tran  programs  [Fosd  76].  We  recently  completed  a  prototype 
of  a  revised  version  of  DAVE  which  facilitates  automatic 
modifications  for  some  dialects  of  Fortran.  Unfortunately, 
all  semantic  specifications  must  be  manually  redesigned  for 
each  such  dialect. 

The  SAM/SAL  system  was  motivated  by  the  desire  to  have 
a  fully  automated  system  which  eliminates  the  ad  hoc  manner 
of  specifying  programming  languages  and  their  dialects. 

JL.2.  Design  Requirements 

SAL  is  a  specification  language  in  which  other  (pro¬ 
cedural)  programming  languages  are  described.  SAL  was 
designed  to  have  the  power  to  capture  all  syntax  and  seman¬ 
tic  descriptions  of  a  large  class  of  programming  languages, 
specifically  for  the  purpose  of  generating  annotated  flow- 
graphs  for  sample  programs  written  in  the  specified 
language. 

The  device  used  for  semantic  specifications  is  a  modi¬ 
fied  form  of  attributed  grammars  [Knuth  68].  It  was  the 
intent  of  this  design  to  take  advantage  of  existing  reli¬ 
able,  portable  software  tools.  At  a  high  level,  we  were 
able  to  use  an  automatic  parser  generating  system,  CLEMSW, 
implemented  on  the  CU  CDC  Cyber  by  Geoffrey  Clemm  [Clemml 
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79].  The  interface  to  this  parse  generator  is  automatically 
provided  by  the  SAM / SAL  system.  The  SAL  compiler  itself  and 
the  main  driver  for  the  semantic  evaluator  are  written  in  a 
slightly  extended  version  of  PASCAL.  This  allows  modifica¬ 
tions  and  extensions  to  be  made  to  the  SAL  compiler  very 
easily,  while  providing  reliable  object  code  by  taking 
advantage  of  an  already  existing  compiler.  (This  also  lends 
some  portability  to  the  SAM/SAL  system  --  a  property  not 
originally  in  the  design  requirements  and  not  completely 
demonstrated  yet) .  At  the  time  of  implementation,  no  CDC 
Cyber  attribute  grammar  systems  were  known  to  be  available. 
Consequently,  the  remainder  of  the  SAM/ SAL  system  was  com¬ 
pletely  designed  and  implemented  from  scratch. 

_1.^3.  Synax  Notation 

Below  is  a  description  of  the  context-free  syntax  used 
to  describe  SAL.  This  notation  is  a  variant  of  the  Backus- 
Naur  Form. 

(a)  Angled  brackets  enclose  grammar  variables,  for  example 

< PROG RAM >  <LIST  OF  ATTRIBUTES> 

< STATEMENT)  <SUB  12> 


(b)  Double-angled  brackets  enclose  grammar  variables  whose 
syntax  and  semantic  rules  are  given  in  the  PASCAL 
Report  and  User's  Manual  [Jensen  74],  for  example 

<  <TYPE>  >  <  < PROCEDURE  OR  FUNCTION  DECLARATION) > 

<< IDENTIFIER) > 


(c)  Reserved  words  and  delimiters  are  enclosed  in  double 
quotes,  for  example 

"BEGIN"  "OBJECT" 


(d)  Square  brackets  enclose  optional  items,  for  example 

< PROGRAM,  HEADING)  [ < PREAMBLE  PART)]  < DECLARATION  PART) 

(e)  Braces  enclose  a  repeated  item.  The  item  may  appear 
zero  or  more  times,  for  example 

< I DENT  LIST)  < IDENTIFIER)  < IDENTIFIER) } 
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1.4.  Language  Outline 

A  SAL  program  is  given  by 

<SAL  PROGRAM >  : :=  "PROGRAM"  < <IDENTIFIER> >  " ; " 

[ < PREAMBLE  SPECIFICATIONS> ] 

< DECLARATION  SPECIFICATIONS > 

< LANGUAGE  SPECIFICATIONS> 

< PROCEDURE  SPECIFICATIONS>  " . " 


Each  of  the  four  specification  parts  are  described  in  detail 
in  Chapters  3  through  6  of  this  report.  The  program  name 
<  <IDENTIFIER>  >  has  no  functional  purpose  other  than  to  name 
the  SAL  program. 

A  SAL  program  specifies  a  single  programming  language. 
In  some  cases,  the  SAL  program  itself  may  serve  as  the 
definition  of  the  language.  However,  the  intended  use  of  a 
SAL  program  is  only  to  capture  enough  of  the  semantics  of  a 
language  (generally  defined  by  other  methods)  to  result  in 
the  generation  of  annotated  flowgraphs  for  programs  written 
in  the  specified  language.  As  a  result,  not  all  language 
semantics  are  necessarily  specified. 


CHAPTER  2 


Lexical  Elements 


This  chapter  defines  the  lexical  elements  of  SAL. 
2.1.  Characters 


The  basic  character  set  consists  of  letters,  digits, 
special  characters,  the  space  character,  and  the  end-of-line 
character  (denoted  by  EOL) . 

(a)  Letters 

ABCDEFGHIJKLMNOPQRSTUVWXYZ 


Implementation  restrictions  require  that  only  upper 
case  letters  be  allowed. 

(b)  Digits 

0123456789 

(c)  Special  characters 

"  #$()[]<>+-/*,.?:  = 

(d)  The  space  character. 

(e)  The  end-of-line  character. 

2-2.  Comments 


SAL  recognizes  two  forms  of  comments: 

(1)  Inline  comments 
The  construct 

( *  <any  sequence  of  characters  not  containing  "*)"  >  *) 


is  an  inline  comment.  Below  are  two  examples  of  inline 
comments . 
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(*  THIS  IS  A  COMMENT  ON  ONE  LINE  *) 

(* 

THIS  IS  A  COMMENT 
OVER  FOUR  LINES 

*) 


(2)  Endline  comments 
The  constructs 

#  <any  sequence  of  characters  except  EOL>  EOL 
or 

$  <any  sequence  of  characters  except  EOL>  EOL 


are  endllne  comments.  An  example  of  an  endline  comment 
is 

# 

#  ENDLINE  COMMENTS  ARE 

#  NICE  FOR  RUNNING  TEXT 

#  ALONG  SIDE  ACTUAL  SAL 

#  CODE. 

# 

All  end line  comments  begin  with  a  "#"  or  and  are 

terminated  by  the  next  end-of-line.  An  endline  comment 
beginning  with  "$"  in  addition  causes  a  page-eject  to 
occur  starting  with  the  next  line  following  the  EOL. 

2.3.  Lexical  Units 

The  lexical  units  of  SAL  include  names,  numbers,  delim¬ 
iters,  and  literals.  Except  as  explicitly  provided,  no  lex¬ 
ical  unit  may  contain  imbedded  spaces,  comments,  or  EOL's. 

2 . 3^ .  1. .  Names 

There  are  essentially  three  types  of  names  recognized 
as  primitive  token  units: 

(a)  Identifiers 

The  syntax  for  identifiers  is  as  in  the  PASCAL  Report, 
and  as  such  its  token  unit  type  is  denoted  by  ^IDEN¬ 
TIFIER^  (see  Section  1.3(b)). 

The  length  of  an  identifier  is  the  number  of  characters 
comprising  its  string. 
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Examples 

START  SUB1  A2B3  SAL  XI 2 345 

(b)  Grammar  identifiers 

The  syntax  for  < GRAMMAR  IDENTIFIER)  is 

< GRAMMAR  IDENTIFIER)  : := 

"<"  < LETTER)  { <LETTER> I <DIGIT> I "  "}  ">" 

The  length  of  a  grammar  identifier  is  the  number  of 
characters  between  its  enclosing  angled  brackets. 

Examples 


< PROGRAM)  < DECLARATION  PART) 

< STATEMENT  LIST)  < FORTRAN  4> 


(c)  Qualified  grammar  identifiers 

The  syntax  for  the  token  unit  <QUAL  GRAMMAR  IDENTIFIER) 
is 


<QUAL  GRAMMAR  IDENTIFIER)  : := 

"<'  < LETTER)  { <LETTER> I <DIGIT> I "  " } 
"("  <DIGIT>  { <DIGIT> }  ")"  ">" 


The  length  of  a  qualified  grammar  identifier  is  the 
number  of  characters  between  its  enclosing  angled 
brackets  minus  its  parenthetic  qualifier. 

Examples 


Qualified  Grammar  Identifier  Length 

< PROGRAM ( 1 ) >  7 

< FORTRAN  4(3) >  9 

< STATEMENT  LIST(2)>  14 

<A1  23  B ( 1 ) >  7 


2>3.2.  Numbers 

There  are  two  types  of  numbers  recognized  by  SAL  as 
token  units. 
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(a)  Integers 

The  syntax  for  integers  is 

<INTEGER>  :  :=  <<UNSIGNED  INTEGER>  > 

Examples 

12345  22222  5432  0 

(b)  Reals 

The  syntax  for  reals  is 

.REAL>  :  :=  <<UNSIGNED  REAL>  > 


Examples 


1.4  25.6E-13  5.0E+12 

0.3  1.498E1  3.14159 


2.3.3.  Literals 

The  token  unit  <LITERAL>  is  any  sequence  of  characters 
not  containing  EOL  and  enclosed  between  two  double  quotes. 
To  include  a  double  quote  in  the  literal,  one  writes  the 
quote  mark  twice. 

The  length  of  a  literal  is  the  number  of  characters 
between  the  two  enclosing  double  quotes.  Two  consecutive 
double  quotes  appearing  within  the  literal  are  counted  as  a 
single  character. 


Examples 

"1"  and  "  "  are  two  literals  of  length  one. 

"AB"  and  """  are  two  literals  of  length  two. 

"IS  THIS  A  ""LITERAL""?"  is  a  literal  of  length  20. 


A  literal  must  have  a  length  greater  than  zero. 
2.3.4.  Delimiters 


The  characters 

(  )  C  1  +  * 


/ 


< 


> 
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Lexical  Elements 


serve  as  one-character  delimiters. 

The  character  strings 

<  >  <=  >=  :  = 

serve  as  two-character  delimiters. 

The  character  string 

serves  as  a  three-character  delimiter. 

2.3.5.  Lexical-Unit  Restrictions 

The  current  SAM/SAL  implementation  restricts  the  length 
of  an  identifier  (2.3.1(a)),  grammar  identifier  (2.3.1(b)), 
and  qualified  grammar  identifier  (2.3.1(c))  to  be  no  more 
than  30  characters.  The  length  of  a  literal  (2.3.3)  may  be 
no  more  than  15  characters. 

2.4.  Sp  ice s 

All  lexical  units  may  be  seperated  by  sequences  of 
spaces,  comments,  or  EOL's.  The  use  of  spaces,  comments, 
and  EOL's  is  mainly  to  provide  readability  and  textual 
organization  to  the  source  program. 

2.5.  Reserved  Words 


The  following  identifiers  are  reserved  words.  The  SAL 
programmer  may  not  use  reserved  word'-,  in  a  context  other 
than  that  explicit  in  the  definition  of  SAL. 


ACTION 

DO 

LABEL 

PREAMBLE 

SPECIFICATIONS 

ACTIONS 

DOWNTO 

LANGUAGE 

PROCEDURE 

SYNTAX 

AND 

ELSE 

MOD 

PROGRAM 

THEN 

ARRAY 

END 

NIL 

RECORD 

TO 

ATTRIBUTE 

FILE 

NODE 

REPEAT 

TOKEN 

ATTRIBUTES 

FLOWGRAPH 

NOT 

RETURN 

TYPE 

BEGIN 

FOR 

OBJECT 

RULES 

TYPES 

CASE 

FUNCTION 

OF 

SCANNER 

UNTIL 

CLASSES 

GOTO 

OR 

SEMANTIC 

VAR 

CONST 

GRAMMAR 

OTHER 

SEMANTICS 

WHILE 

DECLARATIONS 

IF 

PACKED 

SET 

WITH 

DIV 

IN 

CHAPTER  3 


Preamble 


A  given  implementation  of  SAM/SAL  is  expected  to  pro¬ 
vide  a  standard  environment  of  resources  needed  to  aid  the 
SAL  programmer  in  a  language  specification.  The  standard 
environment  should  provide: 

(a)  A  default  lexical  scanner. 

(b)  Predefined  data-structures  to  represent 

(1)  Callgraph  nodes  and  edges 

(2)  Flowgraph  nodes  and  edges 

(3)  Object  Classes 

(4)  Actions 


(c)  Appropriate  predefined  accessing  functions  and  pro¬ 
cedures  for  these  structures. 

A  SAL  preamble  is  an  optional  specificat ion  which  allows  the 
user  to  extend  or  somewhat  control  this  standard  environ¬ 
ment.  Through  the  preamble,  some  implementation  considera¬ 
tions  (which  are  otherwise  meant  to  be  invisible  to  the 
user)  are  made  visible.  The  form  of  a  preamble  is  given  by 

< PREAMBLE  SPECIFICATION  :  :  = 

"PREAMBLE" 

{  < IMPLEMENTATION  SPECS>  ] 

"END"  "PREAMBLE" 

..here  the  form  and  the  content  of  the  implementation  specif¬ 
ications  may  vary  from  one  installation  to  another.  The 
current  implementation  specifications  allowed  on  the  CU  CDC 
Cyber  include  (a)  a  capability  to  override  the  default  lexi¬ 
cal  scanner  by  introducing  another  scanner  more  specific  to 
the  language  being  defined;  (b)  some  capability  to  control 
data-structure  memory  allocation;  and  (c)  the  capability  to 
control  the  form  of  the  parser-grammar  output.  These  three 
capabilities  are  elaborated  below. 

3._1.  Scanner  Specification 

This  would  be  given  by 

< IMPLEMENTATION  SPEC>  : <SCANNER> 


Preamble 


11 


12 


Preamble 


where 

the  form  of  the  scanner 

is 

as  described 

in 

[Clemm2 

793. 

The  scanner  must  return 

four 

"kept"  token 

types 

• 

(1) 

" IDNTFR"  corresponding  to  < IDENTIFIER)  in 
specified  grammar. 

the 

user- 

(2) 

"STRING"  corresponding 
specified  grammar. 

to 

<STRING>  in 

the 

user- 

(3) 

" CNSTNT"  corresponding 
specified  grammar. 

to 

< CONSTANT)  in 

the 

user- 

(4)  "FLOAT"  corresponding  to  <FLOAT>  in  the  user-specified 
grammar . 


In  addition, 

(5)  if  '  s  us  r- specif ied  grammar  uses  any  special  charac¬ 
ter  as  a  literal  token  unit  and  that  character  always 
appe  .i  s  in  literals  of  only  length  1,  then  that  charac¬ 
ter  ife  to  be  returned  as  the  token  type  "SINGLE"  from 
the  scanner,  and 

(6)  if  the  user-specified  grammar  uses  any  special  charac¬ 
ter  as  a  literal  token  unit  and  that  character  may 
appear  in  at  least  one  literal  of  length  greater  than 
one,  then  that  character  is  to  be  returned  by  the 
scanner  as  the  token  type  "MANY" . 

3^2^  Data  Structure  Control 

All  data  structures  provided  by  the  standard  environ¬ 
ment  have  a  default  size.  Most  of  these  structures  may  have 
their  default  size  changed  by  assigning  a  new  size-value  to 
an  appropriate  identifier  in  the  preamble.  Such  assignments 
are  given  by  the  following  syntax 

< IMPLEMENTATION  SPEC >  : 

< PREAMBLE  ID>  < INTEGER> 

where 

< PREAMBLE  ID>  : :=  "MAXSETS"  I  "MAXSETSIZE"  I 

” MAXDPNODES"  I  "MAXEDGES"  | 

"MAXSYM"  I  "MAXCHAR"  I 

" MAXATTBLCK "  I  "MAXPACKET"  j 
"MAXPARSENODES" 


3.2.1,.  MAXSETS  (default  100) 

This  determines  the  number  of  SETS  to  be  reserved  in 
the  SAM/ SAL  set-pool.  The  amount  of  memory  allocated  for 
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sets  is  then  given  by  MAXSETS*MAXSETSIZE  words. 

3.2.2.  MAXSETSIZE  (default  10) 

This  determines  the  number  of  words  to  be  used  in  a 
set.  For  the  CU  CDC  Cyber  59  bits  of  each  word  are  used. 
Thus  if  MAXSETSIZE=3  then  each  set  represents  3  x  59  =  177 
objects . 

3.2.3.  MAXDPNODES  (default  2000) 

his  determines  the  maximum  number  of  dependency-graph 
nodes  that  will  be  reserved  by  the  semantic  evaluator  phase. 
This  graph  controls  the  processing  during  semantic  evalua¬ 
tion  and  is  of  no  direct  interest  to  the  user  except  that 
its  default  size  may  be  inadequate  for  semantic  evaluation 
of  large  source  programs  written  in  the  language  specified. 

3.2.4.  MAXEDGES  (default  2500) 

This  determines  the  maximum  number  of  dependency-graph 
edges  that  will  be  reserved  by  the  semantic  evaluator  phase. 
This  may  need  to  be  explicitly  set  if  the  default  value  is 
inadequate  for  semantic  evaluation  of  large  source  programs 
written  in  the  specified  language. 

3.2.5.  MAXPARSENODES  (default  1000) 

This  determines  the  maximum  number  of  parse-tree  nodes 
that  will  be  reserved  for  the  semantic  evaluator  phase. 
This  may  need  to  be  explicitly  set  if  the  default  value  is 
inadequate  for  semantic  evaluation  of  large  source  programs 
written  in  the  specified  language.  On  the  present  implemen¬ 
tation,  each  parse-tree  node  is  two  central  memory  words. 

3.2.6.  MAXSYM  (default  250) 

This  determines  the  maximum  number  of  symbol  entries 
that  will  be  reserved  for  the  symbol  table  during  the  seman¬ 
tic  evaluator  phase.  On  the  CDC  Cyber,  the  total  symbol 
table  size  can  be  given  by 

MAXSYM  *  (1  +  MAXCHAR/10) 

central  memory  words  where  MAXCHAR  (a  multiple  of  10)  is  the 
maximum  number  of  characters  per  symbol  string. 

2-2.7.  MAXCHAR  (default  10) 

This  determines  the  maximum  number  of  characters  per 
symbol  string  and  should  be  a  multiple  of  the  number  of 
characters  which  can  be  packed  into  a  central  memory  word 
(in  the  case  of  the  CDC  Cyber  series,  a  multiple  of  10). 
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3.2.8.  MAXATTBLCK  (default  250) 

This  determines  the  maximum  number  of  symbol 
attribute-blocks  that  will  be  reserved  for  the  semantic 
evaluator  phase.  The  attribute  table  size  will  then  be 
given  by  MAXATTBLCK  *  N  words  where  N  is  the  maximum  number 
of  symbol  attributes  declared  for  a  given  object  class  (see 
Section  4.1).  Since  a  symbol  may  possess  at  „'.ost  one  attri¬ 
bute  block,  it  is  always  sufficient  for  MAXATTBLCK  to  be 
less  than  or  equal  to  MAXSYM. 

3.2.9.  MAXPACKET  (default  250) 

For  the  current  implementation,  a  packet  is  a  con¬ 
venient  storage  unit  which  holds  action  annotations.  As 
such,  flcwgraph  nodes,  expression-tree  nodes,  and  use-table 
nodes  are  all  packets.  MAXPACKET  determines  the  total 
number  of  packets  to  be  reserved  by  the  semantic  evaluator 
phase.  The  amount  of  memory  occupied  by  packet  allocation 
is 


MAXPACKET  *  (2  +  NUMACT) 

words  where  NUMACT  represents  the  total  number  of  actions 
declared  by  the  user  (see  Section  4.2). 

_3._3«  Grammar  Output  Control 

Often  in  practice  a  group  of  syntax  rules  are  alternate 
rules  for  the  same  grammar  variable.  For  example,  the  list 
of  rules 

<A>  : :=  <B> 

<A>  : :=  <C> 

<A>  : :=  <D> 

can  be  expressed  in  an  "alternatives"  form 

<A>  : :=  <B>  |  <C>  I  <D> 

By  default,  since  syntax  rules  in  SAL  can  never  explicitly 
be  expressed  in  "alternatives"  form  (see  Section  5. 2. 1.1), 
they  are  not  listed  to  the  grammar  output  file  in  this  form. 
However,  the  parser  generator  used  for  the  present  SAL 
implementation  will  require  significantly  less  memory  if  the 
grammar  file  generated  by  SAL  were  in  "alternatives"  form. 
This  can  be  achieved  by  the  ALTERNATIVES  command  in  the 
preamble.  The  syntax  for  this  command  is 

< IMPLEMENTATION  SPEC>  : "ALTERNATIVES" 


An  example  of  a  preamble  is 


Preamble 
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PREAMBLE 

MAXSYM  =  500; 
MAXSETS  =  800; 

ALTERNATIVES; 

END  PREAMBLE 


# 

#  INCREASES  DEFAULT  SYMBOL  TABLE  SIZE. 

#  INCREASE  DEFAULT  SET-POOL  SIZE. 

# 

#  WRITE  GRAMMAR  OUTPUT  FILE 

#  IN  ALTERNATIVES  FORM. 


,  f 

\ 


L-  ) 


CHAPTER  4 


Declarations 


Recall  that  the  key  idea  (see  Section  1.1)  of  a  SAL 
program  is  to  be  able  to  specify  actions  on  objects  at  flow- 
graph  nodes.  The  primary  purpose  of  the  declarations  sec- 
tion  Ts  to  provide  a  mechanism  for  the  user  to  declare 
classes  of  objects  and  actions  for  these  objects  in  order  to 
reflect  the  type  of  node  annotations  desired  on  the  output 
flowgraphs.  The  syntax  for  the  declarations  specifications 
section  ir 

<DECLAkATION  SPECIFICATION  :  :  = 

"DECLARATIONS " 

< OBJECT  CLASS  DECLARATIONS > 

< ACT ION  DECLARATIONS) 

[<FLOWGRAPH  NODE  TYPES)] 

< OTHER  DECLARATIONS) 

"END"  "DECLARATIONS" 

< OBJECT  CLASS  DECLARATIONS),  <ACTION  DECLARATIONS),  ^LOW- 
GRAPH  NODE  TYPES),  and  < OTHER  DECLARATIONS)  are  elaborated 
further  in  Sections  4.1  through  4.4. 

4.1_.  Object  Class  Declarations 

It  is  convenient  to  think  of  objects  as  belonging  to 
classes,  each  class  having  its  own  set  of  actions.  In  PAS¬ 
CAL,  for  example,  the  object  classes  might  correspond  to 
variables,  labels,  procedures,  functions,  and  the  main  pro¬ 
gram.  Of  these  five  classes,  the  user  may  wish  to  associate 
one  or  more  actions  with  only  the  "variables"  class.  In  the 
object  class  declaration  section,  all  object  classes  are 
declared,  along  with  a  (possibly  empty)  list  of  object 
attributes  which  objects  in  that  class  may  possess.  The 
syntax  for  the  object  class  declarations  is 

<OBJECT  CLASS  DECLARATIONS)  : 

"OBJECT"  "CLASSES"  ":" 

<OBJECT  CLASS  SPEC) 

{  <OBJECT  CLASS  SPEC)  } 


<OBJECT  CLASS  SPEC)  : :« 

< OBJECT  CLASS)  ":" 

■("  [ <OBJECT  ATTRIBUTE  LIST)]  ") 
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<OBJECT  CLASS >  : :=  < <IDENTIFIER> > 


<OBJECT  ATTRIBUTE  LIST>  : :=  <OBJECT  ATTRIBUTE  SPEC> 

{  " < OBJECT  ATTRIBUTE  SPEC>  } 


<OBJECT  ATTRIBUTE  SPEC>  : := 

<OBJECT  ATTRIBUTE>  {  < OBJECT  ATTRIBUTE>  } 

" : "  <<TYPE>> 


< OBJECT  ATTRIBUTE)  :  :  =  < <IDENTIFIER> > 

For  example,  in  a  specification  of  PASCAL  one  might  have 

OBJECT  CLASSES  : 

VARIABLES  :  (  )  ; 

LABELS  :  ( FN: FGNODE) ; 

PROCEDURES:  ( PCALL : CALLPTR; PENTRY: FGNODE ) ; 

FUNCTIONS  :  { FCALL: CALLPTR ;FENTRY: FGNODE)  ; 

This  declares  four  object  classes:  VARIABLES,  LABELS,  PRO¬ 
CEDURES,  and  FUNCTIONS.  The  class  VARIABLES  has  no  object 
attributes  associated  with  it.  The  object  class  LABELS  has  a 
single  attribute,  FN,  which  is  of  the  predefined  flowgraph 
node  descriptor  type  FGNODE  (see  Section  B.1.5).  The  object 
classes  PROCEDURES  and  FUNCTIONS  each  have  two  attributes 
associated  with  them;  the  first  (PCALL  and  FCALL,  respec¬ 
tively)  is  of  the  predefined  callgraph  node  descriptor  type 
CALLPTR  (see  Section  B.1.7)  and  is  to  hold  the  callgraph 
node  for  any  object  in  either  of  these  classes;  the  second 
(PENTRY  and  FENTRY,  respectively)  is  to  hold  the  "entry" 
flowgraph  node  for  any  object  in  these  classes. 

An  object  can  be  inserted  into  a  declared  object  class 
via  a  semantic  rule  (see  Section  5.2.2)  or  via  a  SAL  pro¬ 
cedure  or  function  invoked  by  a  semantic  rule  (see  Section 
4.4).  Similarly,  an  attribute  for  an  object  can  be  given  a 
value  via  a  semantic  rule  or  via  a  procedure  or  function 
invoked  by  a  semantic  rule. 

An  Object  Attribute  is  different  from  a  Grammar  Attri¬ 
bute  (Section  5.1)  and  it  is  important  that  the  user  does 
not  confuse  these  two  concepts.  An  Object  Attribute  annotes 
the  object  (or  symbol)  which  possesses  it.  It  may  be 
defined,  referenced,  and  redefined  by  use  of  Attribute  Table 
accessing  functions  (Section  B.2.3).  A  Grammar  Attribute, 
on  the  other  hand,  annotates  a  parse  tree  node  (or 
equivalently,  the  grammar  variable  which  names  that  node), 
and  is  subject  to  the  rigorous  rules  of  attributed  grammar 
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evaluation  [Knuth  68].  As  such,  a  Grammar  Attribute  may  be 
defined  or  referenced  in  a  semantic  rule  (Section  5.2.2), 
but  may  never  be  redefined. 

4.2.  Actions 


Actions  are  declared  for  object  classes.  Each  action 
may  affect  only  one  object  class,  however  Un  object  class 
may  own  zero  or  more  actions.  The  syntax  for  action 
declarations  is 

< ACTION  DECLA RAT IONS >  ::=  "ACTIONS"  " : " 

< ACTION  DEFINITION 
{  < ACTION  DEFINITION  } 


< ACT  10b.  DEFINITION  ::  = 

<  ACTION  {  <  ACTION  }  " :  " 

"ON"  <OBJECT  CLASS>  " ; " 


< ACTION>  j :=  <  <IDENTIFIER>  > 

Continuing  with  our  PASCAL  specification  example,  an  action 
declaration  might  be 

ACTIONS  : 

DEFINE,  REFERENCE,  UNDEFINE  :  ON  VARIABLES; 

USED  :  ON  LABELS; 

Such  a  declaration  would  allow  the  user  to  later  associate 
subsets  of  the  object  class  VARIABLES  with  the  actions 
DEFINE,  UNDEFINE,  and  REFERENCE,  and  associate  subsets  of 
the  object  class  LABELS  with  the  action  USED. 

4.J3.  Flowgraph  Node  Types 

The  user  is  allowed  to  declare  mnemonic  names  for  the 
node  types  of  the  flowgraphs  to  aid  in  program  readability. 
These  names  may  then  be  used  in  a  SAL  statement  which  sets 
the  type  for  a  particular  flowgraph  node.  These  mnemonic 
names  are  automatically  retained  by  the  semantic  evaluator 
phase  for  error  reporting  or  user  displays.  The  syntax  for 
the  flowgraph  node  type  declaration  is 

< FLOWGRAPH  NODE  TYPES>  ; := 

"FLOWGRAPH"  "NODE"  "TYPES"  ":" 

<NODE  NAME>  {  ","  <NODE  NAME>  )  " ; " 

<NODE  NAME>  : :=  <  <IDENTIFIER>  > 


An  example  of  this  declaration  form  for  PASCAL  is 
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FLOWGRAPH  NODE  TYPES  : 

ENTRY,  EXIT,  ASSIGNMENT,  GOTOSTMT,  PROCCALL, 
EMPTYSTMT,  IFTEST,  CASETEST,  WHILETEST, 
REPEATTEST,  FORINIT,  FORTEST,  FORINCR,  FORUNDF ; 


Each  node  name  must  be  no  more  than  ten  characters  in 
length . 


4.4.  Other  Declarations 


The  SAL  user  will  often  find  it  necessary  to  create 
other  procedures  and  functions  based  on  the  primitive  capa¬ 
bilities  provided  by  the  Standard  Environment.  The  newly 
created  procedures  and  functions  are  typically  higher  level 
routines  which  characterize  functional  properties  of  the 
language  being  specified.  The  definitions  of  such  pro¬ 
cedures  and  functions  are  elaborated  in  the  declaration 
specifications  section  of  the  SAL  program.  Any  constants, 
types,  or  global  variables  may  also  be  declared  in  this  sec¬ 
tion.  The  syntax  for  this  is  given  by 

< OTHER  DECLARATIONS >  : := 

<<CONSTANT  DEFINITION  PART>> 

<  <TYPE  DEFINITION  PART>> 

<  <VARIABLE  DECLARATION  PART>> 

<  < PROCEDURE  AND  FUNCTION  DECLARATION  PART>> 

Note  that  any  of  the  four  parts  above  may  be  empty  (as  per 
usual  PASCAL  syntax).  The  motivation  for  providing  this 
declaration  form  in  eAL  will  become  more  apparent  in  Chapter 
5  (specifically,  see  Sections  5. 1.2. 2  and  5.2.2.3(e)). 


CHAPTER  5 


Language  Specifications 


The  language  specifications  section  contains  the  pri¬ 
mary  information  to  specify  a  desired  programming  language. 
The  syntax  for  this  section  is 

< LANGUAGE  SPECIFICATIONS >  : := 

"LANGUAGE"  "SPECIFICATIONS" 

< GRAMMAR  ATTRIBUTE  PART> 

< LANGUAGE  RULES> 

"END"  "LANGUAGE"  "SPECIFICATIONS" 

< G RAMMAR  ATTRIBUTE  PART>  and  < LANGUAGE  RULES>  are  further 
elaborated  in  Sections  5.1  and  5.2,  respectively. 

j>._l.  Grammar  Attributes 

This  subsection  allows  the  user  to  declare  all  of  the 
grammar  variables  to  be  used  in  the  language  specification. 
For  each  such  grammar  variable  a  (possibly  empty)  list  of 
grammar  attributes  is  also  declared.  Each  such  attribute 
must  be  given  a  type. 

jj.l_.I_.  Grammar  Attribute  Part  :  Syntax 

The  syntax  for  the  grammar  attribute  part  is 

< GRAMMAR  ATTRIBUTE  PART>  :  :=» 

"GRAMMAR"  "ATTRIBUTES" 

< GRAMMAR  VAR  ATTLIST> 

{  <GRAMMAR  VAR  ATTLIST>  ) 

"END"  "GRAMMAR"  "ATTRIBUTES" 


< GRAMMAR  VAR  ATTLIST>  : <GRAMMAR  IDENTIFIER> 

{ <GRAMMAR  ATTLIST> )  " ; " 


< GRAMMAR  ATTLIST>  : :=  <G RAMMAR  ATT  DECL> 

{  < GRAMMAR  ATT  DECL> } 

< GRAMMAR  ATT  DECL>  : := 

< GRAMMAR  ATTRIBUTE>  {  <GRAMMAR  ATTRIBUTE>  } 

<<TYPE>> 
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<GRAMMAR  ATTRIBUTE>  ::=  <  <IDENTIFIER>  > 

An  example  of  a  grammar  var  attlist  is 

< LABELLED  STATEMENT >  : 

LABELVAL  :  SYMBOL? 

START,  FINISH  :  FGNODE ; 


j>._1.2:.  Grammar  Attribute  Part  :  Semantics 

A  grammar  var  attlist  serves  to  declare  a  grammar  vari¬ 
able  and  its  associated  grammar  attributes.  Such  a  declara¬ 
tion  allows  the  user  to  later  reference  or  define  the  attri¬ 
buted  variables  (see  Section  5. 2. 2. 2)  constructed  from  a 
grammar  variable  and  any  one  of  its  grammar  attributes.  For 
a  more  complete  discussion  of  the  use  and  meaning  of  grammar 
attributes,  see  [Knuth  68]. 

j>  .^L  ._2  .^L .  Primitive  Grammar  Variables 

Four  predefined  grammar  variables  belong  to  the  set  of 
terminal  symbols  of  any  user-specified  grammar  in  SAL. 
These  four  grammar  variables  are  called  primitive  grammar 
variables  and  include 

< IDENTIFIER>  <CONSTAMT> 

<  FLOAT>  <STRING> 

These  are  the  only  four  grammar  variables  allowed  in  the  set 
of  terminals  for  any  user-specified  grammar  in  SAL.  As  men¬ 
tioned  later  in  the  Syntax  Rule  /  Scanner  Interface  section 
(5. 2. 1.2),  these  terminal  grammar  variables  name  parse  tree 
leaf  nodes  associated  with  "kept”  tokens  ([Clemm2  79])  in 
the  source  code  of  the  parsed  program  being  analyzed.  A 
kept  token  has  two  pieces  of  information  of  use  to  the  SAL 
programmer:  (1)  a  symbol  descriptor  identifying  the  object 

being  kept,  and  (2)  the  token  number  for  the  occurrence  of 
the  object  in  the  source  text.  As  such,  for  each  of  the 
four  primitive  grammar  variables  there  exists  two  predefined 
grammar  attributes?  namely,  VALUE  of  the  standard  type  SYM¬ 
BOL  (Section  B.1.2)  and  TOKEN  of  the  standard  type  INTEGER 
(Section  B.1.9).  The  VALUE  and  TOKEN  attributes  of  any 
primitive  grammar  variable  are  automatically  set  by  SAM/SAL 
to  contain  the  symbol  descriptor  and  token  number,  respec¬ 
tively,  of  the  associated  token  in  the  source  text. 

The  SAL  user  must  observe  the  following  rules  regarding 
the  declaration  of  primitive  grammar  variables. 

(a)  Only  the  four  primitive  grammar  variables  mentioned 
above  may  possess  grammar  attributes  named  VALUE  and 
TOKEN. 
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(b)  A  primitive  grammar  variable  may  possess  no  grammar 
attributes  other  than  VALUE  and  TOKEN. 

(c)  A  user  wishing  to  use  any  of  the  four  primitive  grammar 
variables  must  still  declare  those  grammar  variables 
(along  with  any  of  the  two  special  grammar  attributes 
VALUE  or  TOKEN  desired)  according  to  the  syntax  rules 
of  Section  5.1.1. 

This  discussion  on  the  Grammar  Attribute  Part  in  gen¬ 
eral  and  the  Primitive  Grammar  Variables  in  particular  is 
now  best  illustrated  by  the  following  example: 


# 

#  NO  ATTRIBUTES 

# 

# 

#  WILL  ONLY  USE  "VALUE"  ATTRIBUTE 

#  OF  THIS  PRIMITIVE  GRAMMAR  VAR. 

# 

#  WILL  USE  BOTH  PREDEFINED  ATTRI- 

#  BUTES  FOR  THIS  PRIM.  GRAMMAR  VAR. 

# 

# 

#  THIS  IS  OK,  SINCE  PRIMITIVE. 

#  INVALID...  "NUM"  IS  NOT  A  VALID 

#  ATTRIBUTE  FOR  A  PRIM.  GRAMMAR  VAR 

# 

#  OK,  SINCE  "STATEMENT"  IS  NOT  PRIM. 

#  INVALID. . .  NONPRIMITIVE  GRAMMAR 
VAR  MAY  NOT  HAVE  ATTRIBUTE  NAMED 
"VALUE". 

END  GRAMMAR  ATTRIBUTES  # 

Note  that  this  example  contains  two  (documented)  errors. 
Also,  the  attributed  variables  (see  Section  5. 2. 2. 2) 
< I DENT IF I ER> .VALUE,  <STRING> .VALUE,  and  <CONSTANT> . VALUE  are 
predefined  to  be  the  symbol  descriptors  to  the  identifier, 
string,  and  constant,  respectively,  in  the  symbol  table. 
The  attributed  variable  <STRING> . TOKEN  is  predefined  to  be 
the  token  number  for  the  occurrence  of  the  string  in  the 
source  text  associated  with  this  parse-tree  terminal.  The 
attributed  variable  < STATEMENT >. START  is  not  predefined  and 
must  be  explicitly  defined  by  a  semantic  rule  (see  Section 
5.2.2). 

5._1. 2. 2.  Type  Restrictions 

For  the  current  implementation  of  SAL,  attribute  types 
must  be  either  an  INTEGER  or  subrange  of  INTEGER.  If  a 
grammar  attribute  is  conceived  to  be  of  some  structured  type 
T  (e.g.  a  PASCAL  RECORD  type),  then  the  user  should  define 
the  type  T  in  the  type  definition  part  and  declare  a 


GRAMMAR  ATTRIBUTES 
< PROGRAM >  :  ; 

<  IDEN'f  IFIER>  : 

VALUE  :  SYMBOL? 

<STRING>  : 

VALUE  :  SYMBOL; 
TOKEN  :  INTEGER; 

< CONSTANT >  : 

VALUE  :  SYMBOL; 
NUM  :  INTEGER; 

< STATEMENT >  : 

START  :  FGNODE ; 
VALUE  :  SYMBOL? 
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variable  V  in  the  variable  declaration  part  of  the  declara¬ 
tion  specification  section  ( see  Section  4.4),  so  that  V  is 
some  array  of  type  T.  V  then  acts  as  a  pool  of  resources  of 
type  T,  and  an  index  into  V  then  acts  as  a  descriptor  to  an 
object  of  type  T.  Since  such  an  index  is  a  subrange  of 
INTEGER,  this  descriptor  is  a  valid  grammar  attribute.  This 
is  in  fact  how  SETS,  FLOWGRAPH  NODES,  CALLGRAPH  NODES,  etc. 
are  provided  by  the  current  Standard  Environment.  For  any 
such  pool  of  structured  objects  declared  by  the  user,  the 
user  should  also  carefully  provide  accessing  functions  and 
procedures  to  (1)  allocate  and  deallocate  an  object  in  the 
pool,  and  (2)  set  or  get  fields  within  such  an  object. 

5.2 .  Language  Rules 

The  syntax  for  the  language  rules  subsection  is 

< LANGUAGE  RUI,ES>  :  :=  "RULES" 

<  RULE> 

{ <RULE> ) 

"END"  "RULES" 


<RULE>  ; :=  < SYNTAX  RULE> 

•SEMANTICS" 

C  "OBJECT"  "SPECIFICATIONS" 

< SEMANTIC  RULE  LIST>  ] 

[  "ATTRIBUTE"  "SPECIFICATIONS" 
<SEMANTIC  RULE  LIST>  ] 

[  "FLOWGRAPH"  "SPECIFICATIONS" 
< SEMANTIC  RULE  LIST>  ] 

[  "ACTION"  "SPECIFICATIONS" 

< SEMANTIC  RULE  LIST>  ] 

[  "OTHER"  "SPECIFICATIONS” 

< SEMANTIC  RULE  LIST>  ] 

"  END" 


< SEMANTIC  RULE  LIST>  : :=  < SEMANTIC  RULE> 

{  "?"  < SEMANTIC  RULE>  ) 

The  syntax  rule  of  any  language  rule  is  said  to  "govern"  all 
semantic  rules  in  any  semantic  rule  list  of  that  same 
language  rule.  < SEMANTIC  RULE>  is  further  elaborated  in 
Section  5. 2. 2. 2. 


5.2._1.  Syntax  Rules 

The  collection  of  syntax  rules,  when  combined,  are  to 
form  a  context-free  accepting  grammar  and  tree-building 
grammar  for  the  specified  language.  If  the  language  being 
specified  is  not  context  free  (e.g.  Fortran  66),  then  the 
user  must  carefully  define  a  powerful  lexical  scanner  in  the 
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preamble  (see  Section  3.1)  to  resolve  all  context-sensitive 
features . 

S.2.1.1.  Syntax  Rule  Syntax 

The  syntax  of  a  syntax  rule  is 
< SYNTAX  RULE>  ::= 

< GRAMMAR  VARIABLE>  "  < SYNTAX  EXPRESSION 

< GRAMMAR  VARIABLE)  : s=  <GRAMMAR  IDENTIFIER)  I 

<QUAL  GRAMMAR  IDENTIFIER) 

< SYNTAX  EXPRESSION)  ::=  < SYNTAX  UNIT)  { < SYNTAX  UNIT)} 

< SYNTAX  UNIT)  : :=  < GRAMMAR  VARIABLE)  I  <LITERAL> 

Examples 

< PROGRAM)  : :=  <HEADING>  < DECLARATIONS)  < BODY) 

<STMT  LST ( 1 ) >  :  :=  < STATEMENT)  " ; "  < STMT  LST(2)> 


The  presence  of  a  qualifier  in  a  grammar  variable  has 
no  effect  on  the  syntax  rule.  Qualifiers  are  a  semantic 
device  only  (see  Section  5.2.2.3(b)).  Thus,  the  two  syntax 
rules  below  are  grammatically  indistinguishable: 

< I DENT  LIST ( 1 ) >  : :=  < I DENT  LIST(2)>  < IDENTIFIER) 

< I DENT  LIST)  ::=  < I DENT  LIST)  < IDENTIFIER) 


The  length  of  a  grammar  variable  is  the  length  of  the 
grammar  identifier  (Section  2.3.1(b))  or  qualified  grammar 
identifier  (Section  2.3.1(c))  which  it  derives. 

J5.2.1_.2.  Syntax  Rule  /  Scanner  Interface 

In  Section  3.1  it  was  mentioned  that  four  special  token 
types  must  be  provided  by  the  lexical  scanner.  These  types 
correspond  to  the  "kept"  tokens  ([Clemm2  79])  in  a  given 
source  stream,  and  correspond  with  the  four  primitive  gram¬ 
mar  variables  mentioned  in  Section  5. 2. 1.2*  Explicitly, 
this  correspondence  is  given  by 


" IDNTRF" 

<  --> 

IDENTIFIER) 

"STRING" 

<  —  > 

<STRING> 

" CNSTNT" 

<--> 

< CONSTANT) 

" FLOAT" 

<  —  > 

< FLOAT) 

This  correspondence  is  automatically  known  to  SAM/ SAL. 
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final  details  of  the  interface  protocol  are  automatically 
handled  by  SAM/SAL. 

5.2. 1.3.  Syntax  Rule  Restrictions 

There  are  four  restrictions  to  the  collection  of  syntax 
rules.  The  first  two  restrictions  have  to  do  with  general 
requirements  of  a  context-free  grammar.  The  last  two  res¬ 
trictions  are  due  to  implementation  requirements  peculiar  to 
the  automatic  parser  generator. 

(1)  There  must  exist  exactly  one  grammar  variable  (called 
the  start  variable)  which  is  the  left  side  of  at  least 
one  syntax  rule  and  which  appears  on  the  right  side  of 
no  syntax  rule. 

(2)  The  primitive  grammar  variables  (see  Section  5. 1.2.1) 
may  not  appear  on  the  left  side  of  any  syntax  rule. 

(3)  The  right  side  of  a  syntax  rule  may  not  be  empty. 
Unfortunately,  this  may  force  a  large  increase  in  the 
number  of  syntax  rules  than  might  otherwise  be  possible 
if  the  empty  production  were  permitted. 

(4)  The  right  side  of  a  syntax  rule  may  have  at  most  seven 
syntax  units . 

Semantic  Rules 

The  semantic  rules  specified  in  SAL  may  be  partitioned 
into  five  phases:  OBJECT  SPECIFICATIONS,  ATTRIBUTE  SPECIFI¬ 
CATIONS,  FLOWGRAPH  SPECIFICATIONS,  ACTION  SPECIFICATIONS, 
and  OTHER  SPECIFICATIONS.  The  use  of  these  phases  is  a  sim¬ 
ple  variation  on  a  pure  attributed  grammar  as  defined  in 
[Knuth  68],  and  is  explained  as  follows.  After  some  prac¬ 
tice  at  using  the  pure  nonprocedural  attributed  grammar  dev¬ 
ice,  it  became  clear  that  a  specification  program  using  such 
a  device  was  intellectually  more  managable  if  it  was  at 
least  conceived  of  as  a  sequence  of  successive  phases,  where 
the  run-time  completion  of  a  phase  could  be  characterized  as 
the  completion  of  some  conceptual  user-level  task.  In  a  SAL 
program,  the  user's  job  is  to  create  objects  (update  a  sym¬ 
bol  table),  possibly  decorate  these  objects  (create  object 
attributes  in  an  attribute  table),  build  flowgraphs,  anno¬ 
tate  flowgraph  nodes  with  actions,  and  possibly  perform 
other  miscellaneous  activities  on  these  structures.  The 
five  phases  mentioned  above  are  intended  to  correspond  to 
these  five  conceptual  activities.  The  semantic  rules  within 
a  phase  are  directed  toward  performing  these  corresponding 
activities.  The  concept  of  partitioning  semantic  rules  into 
phases  thereby  allows  a  user  to  build  or  update  global 
structures  (symbol  table,  attribute  table,  flowgraph  node 
table,  edge  lists,  action  packets,  etc.)  without  having  to 
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pass  copies  of  these  large  structures  up  and  down  the  parse 
tree . 


This  night  be  better  realized  with  the  following  illus¬ 
tration.  In  order  to  create  an  object  attribute  in  the 
attribute  table  the  object  must  first  exist  as  a  symbol 
table  entry.  A  semantic  rule  relying  on  either  the  object 
being  in  the  symbol  table  or  one  of  its  attributes  being  in 
the  attribute  table  must  not  execute  until  such  table 
updates  have  been  made.  One  expensive  (but  pure)  method  of 
signalling  the  semantic  rule  that  the  updates  it  requires 
have  indeed  been  made  is  to  propogate  a  set  of  grammar 
attributes  up  and  down  the  parse  tree  to  signal  the  comple¬ 
tion  of  the  symbol  table  update  phase,  and  then  propogate 
another  set  of  grammar  attributes  up  and  down  the  parse  tree 
to  signal  the  end  of  the  attribute  table  creation  phase. 
The  propog? tion  of  such  grammar  attributes  is  costly  both  in 
terms  of  memory  (as  many  as  two  extra  attributes  needed  per 
parse  tree  node  per  phase)  and  in  terms  of  time  (each  attri¬ 
bute  would  have  to  be  readied,  scheduled,  and  computed). 

With  the  semantic  rule  partitioning  introduced  in  SAL, 
all  of  this  effort  of  defining  and  propogating  extra  grammar 
attributes  for  end-of-phase  signalling  can  be  eliminated  or 
greatly  reduced. 

Evaluation  Order  of  Semantic  Pules 

The  collection  of  all  semantic  rules  specify  a  nonpro¬ 
cedural  set  of  instructions.  It  is  generally  not  clear  from 
the  source  text  ordering  of  these  rules  what  their  actual 
evaluation  order  might  be. 

_5. 2. 2. ]L. 1_.  Interphase  Ordering 

The  phase-partitioning  mentioned  above  (5.2.2)  has  the 
following  interpretation:  no  semantic  rule  in  a  given  seman¬ 
tic  phase  can  execute  until  all  semantic  rules  in  any 
preceding  phase  have  executed.  This  of  course  implies  an 
ordering  to  the  semantic  phases.  Explicitly,  this  ordering 
is 

(1)  The  OBJECT  SPECIFICATIONS  phase  is  first  and  therefore 
has  no  preceding  phase.  All  semantic  rules  in  this 
phase  are  therefore  constrained  by  no  rules  from  other 
phases.  The  intent  of  this  phase  is  to  contain  (among 
other  rules)  those  semantic  rules  which  update  the  sym¬ 
bol  table  by  creating  objects  (symbols). 

(2)  The  ATTRIBUTE  SPECIFICATIONS  phase  is  second.  All 
semantic  rules  in  this  phase  execute  only  after  the 
semantic  rules  in  the  OBJECT  SPECIFICATIONS  phase  have 
executed.  The  intent  of  this  phase  is  to  be  able  to 
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rely  on  the  existence  of  a  completed  symbol  table  from 
the  previous  phase  so  that  any  associated  symbol  attri¬ 
butes  may  now  be  added  to  the  attribute  table. 

(3)  The  FLOWGRAPH  SPECIFICATIONS  phase  is  third.  The  intent 
of  this  phase  is  to  build  flowqraph  nodes  and  edges 
relying  on  the  existence  of  a  completed  symbol  table 
and  attribute  table.  A  semantic  rule  in  this  phase  may 
execute  only  after  all  semantic  rules  in  the  OBJECT 
SPECIFICATIONS  and  ATTRIBUTE  SPECIFICATIONS  phase  have 
executed . 

(4)  The  ACTION  SPECIFICATIONS  phase  is  fourth.  The  intent 
of  this  phase  is  to  annotate  the  nodes  in  the  flow- 
graphs  created  by  the  previous  (FLOWGRAPH  SPECIFICA¬ 
TIONS)  phase.  A  semantic  rule  in  this  phase  may  exe¬ 
cute  only  after  all  semantic  rules  in  the  OBJECT 
SPECIFICATIONS,  ATTRIBUTE  SPECIFICATIONS,  and  FLOWGRAPH 
SPECIFICATIONS  phases  have  executed. 

(5)  The  OTHER  SPECIFICATIONS  phase  is  fifth  and  last.  The 
intent  of  this  phase  is  to  allow  the  specification  of 
any  additional  semantic  rules  which  may  rely  on  the 
existence  of  all  tables  and  structures  completed  by  the 
previous  four  phases.  A  semantic  rule  in  this  phase 
may  execute  only  after  all  semantic  rules  in  any  of  the 
other  four  phases  have  executed. 

5-2.2.1-2.  Intraphase  Ordering 

Within  a  phase  semantic  rules  are  executed  in  an  order 
determined  by  their  dependencies  on  the  other  grammar  attri¬ 
butes  (see  [Knuth  68]).  In  general  this  will  not  be  a  total 
order  in  that  at  any  given  moment  more  than  one  semantic 
rule  may  be  ready  for  execution.  The  determination  of  gram¬ 
mar  attribute  dependencies,  detection  of  which  semantic 
rules  at  a  given  moment  are  ready  for  execution,  and 
scheduling  of  all  "ready"  rules  for  execution  is  automati¬ 
cally  handled  by  the  SAM/ SAL  semantic  evaluator. 

An  additional  intraphase  ordering  imposed  by  SAL  is 
that  all  assignment  rules  are  executed  before  any  procedure 
rule .  “ 

5. 2. 2. 1^.3.  Evaluation  Order  Restrictions 

It  is  possible  to  have  a  collection  of  semantic  rules 
which  cannot  all  execute.  A  simple  example  of  this  is 
illustrated  by  the  following  language  rule. 
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<A>  : :=  <B> 

SEMANTICS 

OTHER  SPECIFICATIONS 

< A> . ATT1  :=  FI ( <B> . ATT1 )  ; 

<  B> . ATT1  :=  F2  (  A>  . ATT1 ) 

END 

From  the  first  semantic  rule  in  the  example  it  is  clear  that 
< A> . ATT1  cannot  be  evaluated  until  after  the  evaluation  of 
< B> . ATT1 •  But  from  the  second  rule  we  see  that  <B>.ATT1 
cannot  be  evaluated  until  after  the  evaluation  of  <A>.ATT1. 
From  the  point  of  view  of  the  SAM/SAL  scheduler,  a  deadlock 
exists . 

A  SAL  program  in  which  all  semantic  rules  can  be 
evaluated  without  interdependency  conflicts  is  called  well 
defined .  A  valid  SAL  progran  must  be  well-defined,  and  “the 
user  must  exercise  care  to  ensure  this  behavior.  The  detec¬ 
tion  of  any  violations  of  a  well-defined  program  occurs  in 
the  semantic  evaluation  phase  and  not  during  program  compi¬ 
lation  . 

Research  performed  by  other  authors  ([Boehm  76],  [Jazay 
75],  [Kasten  78],  and  [Kenned  76])  has  been  done  to  investi¬ 
gate  methods  for  improving  semantic  evaluation  by  enforcing 
a  fixed  evaluation  strategy  on  the  attribute  grammar.  In 
all  cases,  these  improvements  were  achieved  by  restricting 
the  class  of  attribute  grammars  accepted  from  the  well- 
defined  class  above. 

J>‘2.2.2.  Semantic  Rule  Syntax 

The  syntax  for  a  semantic  rule  is 
< SEMANTIC  RULE >  :  :=  ASSIGNMENT  RULE>  I  PROCEDURE  RULE> 


ASSIGNMENT  RULE>  :  :  = 

< ATTRIBUTED  VARIABLE>  "  < SEMANTIC  EXPRESSION 


< PROCEDURE  RULE>  : := 

<  < IDENTIFIER>  >  {"("  <SEMANT IC  EXPRESSION  LIST)  ")"  ) 


< SEMANTIC  EXPRESSION  LIST)  : := 

< SEMANTIC  EXPRESSION  < SEMANTIC  EXPRESSION  ) 


< ATTRIBUTED  VARIABLE>  :  :  = 
<GRAMMAR  VARIABLE> 


< GRAMMAR  ATTRIBUTE) 
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OEM  ANTIC  EXPRESSION)  i  :  = 

< SEMANTIC  SUBEXPRESSION) 

<SET  0P>  OEM  ANTIC  SUBEXPRESSION)  I 
OEM  ANTIC  SUBEXPRESSION) 


OET  0P>  :  :=  "UNION"  I  "INTERSECTION"  i  "MINUS" 


< SEMANTIC  SUBEXPRESSION)  ::= 

< SEMANTIC  TERM)  ADD  0P>  OEMANTIC  TERM)  I 
< SEMANTIC  TERM) 


< ADD  0P>  : :=  "+"  I  "-" 


< SEMANTIC  TERM)  : := 

< SEMANTIC  FACTOR)  <MULT  0P>  < SEMANTIC  FACTOR)  | 
< SEMANTIC  FACTOR) 


<MULT  OP>  : |  "/" 


< SEMANTIC  FACTOR)  : := 

<  INTEGER)  |  <REAL>  I  <  <IDENTIFIF.R>  >  | 

< FUNCTION  REFERENCE)  I  ATTRIBUTED  VARIABLE)  I 

<  < S I GN >  >  OEMANTIC  FACTOR)  I 
"(”  < SEMANTIC  EXPRESSION)  ")" 


< FUNCTION  REFERENCE)  ::= 

<  <IDENTIFIER>  >  {"("  <SEMANTIC  EXPRESSION  LIST)  ")") 


^•2.2^3.  Semantic  Rule  Semantics 

(a)  For  an  attributed  variable  appearing  in  any  semantic 
rule,  the  following  must  hold. 

(1)  The  grammar  attribute  composing  the  attributed 
variable  must  appear  in  the  grammar  attribute  list 
for  the  declaration  of  the  associated  (unquali¬ 
fied)  grammar  identifier  (see  Section  5.1.2). 

(2)  The  grammar  variable  part  of  the  attributed  vari¬ 
able  must  appear  in  the  syntax  rule  governing  (see 
Section  5.2)  the  semantic  rule  containing  the 
attributed  variable. 


(b)  A  qualified  grammar  identifier  is  syntactically  inter¬ 
preted  no  differently  than  the  same  grammar  identifier 
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without  the  qualifier.  However,  in  semantic  rules  such 
qualifiers  are  often  needed  to  destinguish  between  two 
or  more  occurrences  of  the  same  grammar  variable.  This 
is  best  illustrated  by  an  example  of  a  language  rule: 

<ID  LIST  ( 1 )  >  :  <ID>  ** ,  "  <ID  LIST(2)> 

SEMANTICS 

OBJECT  SPECIFICATIONS 

<1D>. ENVIRON  :=  <ID  LIST( 1 )>. ENVIRON 

END 

The  syntax  rule  describes  a  subtree  of  the  parse  tree 
rooted  at  <ID  LIST(1)>  and  having  two  sons  <ID>  and 
<ID  LIST(2)>.  The  semantic  rule  explicitly  assigns  to 
the  ENVIRON  attribute  of  <ID>  the  ENVIRON  attribute  of 
the  root  of  this  subtree.  Without  qualifiers  on 
<  ID  L JST>  such  a  semantic  rule  would  be  ambiguous  since 
< ID  j_,1ST>  .  ENVIRON  could  refer  to  the  ENVIRON  attribute 
of  either  the  subtree  root  or  the  second  son. 

(c)  The  qualifier  numbering  within  a  language  rule  is  up  to 
the  user.  The  only  restriction  is  that  a  specific 
qualified  grammar  variable  may  appear  at  most  once  in  a 
given  syntax  rule.  Thus  the  following  is  invalid 

< A( 1 ) >  : :=  <A{ 1 )  >  "ELSE"  <B> 

since  the  qualified  grammar  variable  <A(1)>  appears 
twice  in  the  same  syntax  rule.  The  following  two  exam¬ 
ples  are  valid 

<A>  : :=  <A>  "ELSE"  <B> 

<  B ( 1 ) >  :  :=  <B( 2 ) >  <A(1)>  <A(2)> 

In  the  first  example,  since  <A>  is  not  qualified  it  may 
appear  more  than  once  in  the  syntax  rule.  However  it 
may  not  appear  as  part  of  an  attributed  variable  in  a 
semantic  rule  since  such  an  attributed  variable  would 
result  in  an  ambiguous  reference.  In  the  second  exam¬ 
ple,  each  qualified  grammar  variable  is  correctly  used 
at  most  once  in  the  syntax  rule. 

(d)  The  length  of  a  grammar  attribute  is  the  number  of 
characters  in  the  attribute  name.  The  length  of  an 
attributed  variable  is  the  length  of  its  grammar  vari¬ 
able  part  ( Section  5. 2. 1.1)  plus  the  length  of  its 
grammar  attribute  part  plus  one.  For  example,  the 
grammar  attribute  ENVIRON  has  length  7,  and  the  attri¬ 
buted  variable  <ID  LIST{ 1 2 )>• ENVIRON  has  length  15. 
The  current  SAM/ SAL  implementation  restricts  the  length 
of  any  grammar  attribute  and  attributed  variable  to  be 
no  more  than  30. 
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(e)  A  Procedure  Rule  or  Function  Reference  may  apply  to  any 
procedure  or  function  declared  either  in  the  Standard 
Environment  (see  Appendix  B)  or  in  the  Other  Declara¬ 
tions  section  (see  Section  4.4). 


CHAPTER  6 


Procedural  Specifications 


This  final  specification  section  of  a  SAL  program 
allows  the  user  to  perform  any  post  semantic  computations  to 
augment  the  output  listing  file  of  the  semantic  evaluator 
phase  of  SAM/ SAL.  Any  computations  in  this  section  will 
automatically  occur  after  all  semantic  rules  have  been  com¬ 
puted,  and  after  the  symbol  table,  callgraph  tables,  and 
flowgraph  tables  have  been  dumped  to  the  output  tables  file. 
Thus  any  computations  occuring  in  this  section  cannot  alter 
the  output  tables  file.  The  computations  may  (and  indeed 
are  intended  to)  add  to  the  output  listing  file.  All  global 
variables  provided  by  the  Standard  Environment  or  declared 
by  the  user  in  the  Other  Declarations  pare  (4-4)  are  avail¬ 
able  for  use  here.  This  specification  section  was  added  to 
the  SAL  language  to  provide  the  user  with  some  post  semantic 
control .  It  is  expected  that  in  most  SAL  programs  there 
will  no  code  in  this  specification  section.  The  syntax  for 
the  procedural  specifications  section  is 

< PROCEDURAL  PART>  :  :  = 

"PROCEDURE"  "SPECIFICATIONS" 

< OTHER  DECLARATIONS > 

"BEGIN" 

<  <STATEMENT>  > 

{  "?"  << STATEMENT > >  } 

"  END" 

"END"  "PROCEDURE"  "SPECIFICATIONS" 

where  < <STATEMENT> >  has  the  usual  PASCAL  syntax  and  seman¬ 
tics,  and  in  particular  may  be  empty.  Examples  of  a  pro¬ 
cedural  specification  are 

(1)  PROCEDURE  SPECIFICATIONS  #  EXAMPLE  OF  AN  EMPTY 

BEGIN  #  PROCEDURE  SPECIFICATION 

END  # 

END  PROCEDURE  SPECIFICATIONS  # 

and 
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(2)  PROCEDURE  SPECIFICATIONS 

<* 

WRITE  THE  COMPLETED  SYMBOL  TABLE  TO 
THE  STANDARD  FILE  "OUTPUT" . 

*) 

VAR 

SYM  :  SYMBOL; 

BEGIN 

WRITELN("  DUMP  OF  SYMBOL  TABLE") 
FOR  SYM : =1  TO  NUMSYM  DO 
BEGIN 

WRITE ("  " :5, SYM : 5 , "  " : 5 ) ; 
WRITESYM( OUTPUT, SYM) ? 
»RITELN 

END 

END 

END  FROCEDURE  SPECIFICATIONS 
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Using  SAM/ SAL  on  the  CU  CDC  Cyber 


Each  of  the  phases  listed  below  uses  special  files 
built  for  the  SAM/ SAL  system.  The  names  of  these  files,  and 
the  CU  projects  and  CCID's  under  which  they  are  accessed  may 
change.  The  file  names,  projects,  and  CCID's  given  below 
are  valid  as  of  January,  1981. 


A . 1  Compiling  a  SAL  Program,  S 

Nine  output  files  are  generated  by  the  SAL  compiler. 
Of  these,  six  have  SAM/ SAL  system  names  which  are  not  to  be 
altered  by  the  user,  and  thus  do  not  explicitly  appear  in 
the  compile  command.  To  compile  a  SAL  source  program,  S: 

GET, SAL=SALTRAN/PAPM , J973 . 

SAL, S, SALIST, SCANNER, GRCLEM . 

The  single  input  file  is: 

S  User  specified  source  file  to  be  compiled. 

The  nine  output  files  are: 

SALIST  Listing  file.  This  includes  a  paginated  copy  of 
the  original  source  text  with  line  numbers,  error 
diagnostics,  cross-reference  information,  and 
program  statistics. 

SCANNER  Scanner  file.  This  file  contains  the  default  or 
user-defined  scanner  specifications  to  be  used  by 
FSCAN. 

GRCLEM  Grammar  file.  This  file  contains  all  sytax  rules 
in  the  form  expected  by  the  tree-builder  phase  of 
parse  generation. 

DECLF  Declarations  file.  This  file  contains  all 
declarations  as  specified  in  4.4. 

EVALF  Command  Evaluation  file.  This  file  contains  all 
semantic  rules  translated  into  PASCAL  statements. 

DGRAPHF  Dependency-Graph  file.  This  fii  contains  the 
sequence  of  PASCAL  commands  generated  by  SAL  to 
build  the  dependency  graph  for  any  program  in  the 
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specified  language  for  analysis  by  the  semantic 
evaluator . 

CNSTMOD  Constants  file.  This  file  contains  all  constants 
which  govern  the  size  of  the  Standard  Environment 
data  structures. 

PTCLF  Productions  Table  file.  This  file  contains  PAS¬ 
CAL  code  for  creation  of  the  productions  table  in 
the  semantic  evaluator. 

SALBODY  Body  file.  This  file  contains  PASCAL  code  as 
specified  in  Chapter  6. 


A. 2  Generating  the  Evaluators 


A. 2.1  Parser  Generation 

To  automatically  generate  a  parser  for  the  language 
specified  by  S,  the  two  output  files  SCANNER  and  GRCLEM  from 
SAL  are  needed.  Parse  generation  proceeds  over  several 
phases . 


Phase  1.  Process  Scanner  Specifications. 

GET, FSCAN/PAPM, J973 . 

FSCAN, SCANNER, SCNLST, TBLl , ERRSCN. 

The  single  input  file  is: 

SCANNER  Output  from  SAL  compiler. 

The  three  output  files  are: 

SCNLST  Scanner  listing  file. 


TBLl 


Fortran  tables  produced  by  FSCAN. 


ERRSCN  Error  file. 

If  ERRSCN  is  empty,  then  you  can  proceed  to  the  second  phase 
of  parse  generation. 


Phase  2.  Process  Scanner/Grammar  Interface. 

GET , SALTGB/ PAPM , J9  7  3 . 

SALTGB , GRCLEM , TBLl , GRLIST , TBL2 , TBL3 , ERRTGB . 


The  two  input  files  are: 
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GRCLEM  Output  from  SAL  compiler. 

TBL1  Output  from  FSCAN. 

The  four  output  files  are: 

GRLIST  Tree-grammar  listing  file. 

TBL2  Fortran  tables  produced  by  SALTGB . 

TBL3  Grammar  table  produced  by  SALTGB. 

ERRTGB  Error  file. 

If  ERRTGB  is  empty,  you  can  proceed  to  the  third  phase  of 
parse  generation. 

Phase  3.  Create  Fortran  Grammar  Tables. 

GET, CLEMSW=CLMSWB/PAPM, J973. 

CLEMSW, TBL3 , CLMLIST, TBL4 . 

The  single  input  file  is: 

TBL3  Output  from  SALTGB. 

The  two  output  files  are: 

CLMLIST  CLEMSW  listing  file. 

TBL4  Fortran  table  produced  by  CLEMSW. 

If  no  errors  were  detected  by  CLEMSW,  you  can  proceed  to  the 
final  phase  of  parse  generation. 


Phase  4.  Producing  the  Actual  Parser. 

To  produce  the  actual  parser  for  the  language  specified 
by  S,  the  Fortran  tables  produced  in  the  previous  phases 
need  to  be  compiled  and  edited  into  a  parse-driver  template. 
The  KCL  for  this  phase  is: 

REWIND, TBL1 , TBL2 , TBL4 . 

FTN,  I=TBL1,L=0,  B=*BIN. 

FTN, I=TBL2,L=0, B=BIN. 

FTN, I*TBL4,L*0, B=BIN. 

REWIND, BIN. 

GET, PRSDRVB/PAPM, J973. 

L1BEDIT, P=PRSDRVB , L=0 , B=BIN , I»0,N»PARSE. 

The  three  input  files  are: 
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TBL1  Output  from  FSCAN. 

TBL2  Output  from  SALTGB . 

TBL4  Output  from  CLEMSW. 

The  single  output  file  is: 

PARSE  Object  file  for  the  parser  for  the  language 
specified  by  S. 

A. 2. 2  Semantic  Evaluator  Generation 

To  build  a  semantic  evaluator  for  S: 

GET, CENEVAL/PAPM , J973 . 

PASCAL, GENEVAL, GENLIST, SMEVAL. 

The  six  (implicit)  input  files  are: 

EVALF,  DGRAPHF ,  PTCLF,  SALBODY,  DECLF ,  and  CNSTMOD 
Output  files  from  the  SAL  compiler. 

The  two  output  files  are: 

GENLIST  PASCAL  listing  of  the  semantic  evaluator. 

SMEVAL  Object  file  for  the  semantic  evaluator  for  the 
language  specified  by  S. 

A. 3  Using  the  Evaluators 

This  section  describes  how  to  use  the  parser  and  seman¬ 
tic  evaluator  created  in  Section  A. 2. 

A. 3.1  Using  the  Parser 

To  parse  a  program  U  in  the  language  specified  by  S: 
PARSE, U, ULIST, UTBL, UERR. 

The  two  input  files  ares 

PARSE  The  parser  generated  in  A. 2.1. 

U  A  sample  program  in  the  language  specified  by  S. 

The  three  output  files  are: 
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ULIST  A  listing  of  file  U  with  token  numbers. 

UTBL  File  containing  symbol  table  and  parse-tree  for 

U. 

UERR  Listing  of  syntax  errors  in  U. 


A. 3. 2  Using  the  Semantic  Evaluator 

To  perform  the  semantic  evaluation  of  program  U  as 
specified  by  S: 

GET, FTNSETB/PAPM, J973 . 

LOAD, FTNSETB . 

SMEVAL, UTBL, SAMLIST, SAMTBL. 

The  two  inpit  files  are: 

SMEVAL  The  semantic  evaluator  generated  in  A. 2. 2. 

UTBL  The  table-file  generated  by  the  parser  for  pro¬ 

gram  U. 

The  two  output  files  are: 

SAMLIST  Listing  file  containing  (a)  any  system  errors 
detected  by  the  semantic  evaluator,  (b)  any  out¬ 
put  requests  issued  by  the  user  in  S,  and  (c) 
program  statistics  for  U. 

SAMTBL  This  file  contains  the  symbol  table,  call  graph, 
and  flowgraphs  for  program  U. 


A. 4  Fancy  Display 

The  current  SAM/SAL  system  has  a  post  phase  which 
allows  the  user  to  get  a  readable  listing  of  the  tables  file 
from  the  semantic  evaluator.  To  invoke  this  display  tool: 

GET, SAL POST/ PAPM , J973 . 

SALPOST, SAMTBL, PLIST. 

The  single  input  file  is: 

SAMTBL  Output  from  semantic  evaluator. 

The  single  output  file  is: 

PLIST  User-readable  listing  of  input. 
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The  Standard  Environment 


This  appendix  lists  the  Standard  Environment  TYPES, 
PROCEDURES  and  FUNCTIONS  for  the  SAM/SAL  system. 


B.l  Standard  Types 
B.1.1  Set  types 

SETS  SET  descriptor  type 

UNPSET  Unpacked  representation  of  a  set 


B.l. 2  Symbol  Types 

SYMBOL  Symbol  descriptor  type 

OBJECT  Synonym  for  SYMBOL 


SYMREP 

SYMLNG 

UNPSTR 


Type  for  the  character  string  of 
a  symbol 

Subrange  type  for  the  length  value  of 
a  symbol 

Unpacked  type  for  SYMREP 


B.l. 3  Symbol  Attribute  Types 

ATTRIBUTE  Attribute-name  selector  type 

ATTBLOCK  Attribute-block  descriptor 

B.l. 4  Object  Class  Types 

OBJCTCLASS  Object-Class  name  type 
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B.1.5  Packet  Types 
PACKET 
ACTION 
FGNODE 
EXPNODE 


Flowgraph  node,  expression-tree  node, 
use-table  node  descriptor  type 
Scalar  type  of  user-defined  actions 

Synonym  for  PACKET 

Synonym  for  PACKET 


B.1.6  Parameter  Building  Types 

FPRMPTR  Formal  parameter  node  descriptor 

B.1.7  Callgraph  Types 

CALLPTR  Callgraph  node  descriptor  type 


B.1.8  Parse-Tree  Types 

PARSENODE  Parse-tree  node  descriptor  type 

B.1.9  Other  Types 

These  include  all  other  primitive  types  provided  by  the 
PASCAL  Report  ([Jensen  74]).  Specifically 

INTEGER 

REAL 

CHAR 

BOOLEAN 


B.2  Standard  Procedures/Functions 

B.2.1  Set  Routines 

FUNCTION  NEWSET : SETS ; 

(* 

*> 


RETURNS  A  NEW  (EMPTY)  SET  FROM  THE  SET-POOL. 
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FUNCTION  NULLSETsSETS; 

(* 

SAME  AS  NEWSET 

*) 


PROCEDURE  RETURNSET ( VAR  S : SETS ) ; 

(* 

RETURNS  A  SET  TO  THE  SET-POOL. 

*) 


FUNCTION  ISEMPTY( S: SETS ): BOOLEAN; 

(* 

RETURNS  TRUE  <=>  SET  S  IS  EMPTY. 

*) 


PROCEDURE  UNIONP(Sl, S2: SETS;  VAR  RESULT : SETS ) ; 

(* 

RETURNS  A  NEW  SET  RESULT  WHOSE  VALUE  IS  THE 
UNION  OF  SETS  SI  AND  S2. 

*) 


FUNCTION  UNION (SI, S2 : SETS) : SETS; 

(* 

SAME  AS  UNIONP  EXCEPT  THIS  IS  A  FUNCTION,  AND 
HENCE  HAS  NO  CONTROL  OF  GARBAGE  COLLECTING  ON 
USED  SETS. 

*) 


PROCEDURE  INTERSECTP (SI, S2 : SETS ;  VAR  RESULT : SETS ) ; 

(* 

RETURNS  A  NEW  SET  RESULT  WHOSE  VALUE  IS  THE 
INTERSECTION  OF  SETS  SI  AND  S2. 

*) 


FUNCTION  INTERSECT ( SI , S2 : SETS ) ; SETS ; 

(* 

SAME  AS  INTERSECTP  EXCEPT  THIS  IS  A  FUNCTION, 
AND  HENCE  HAS  NO  CONTROL  OF  GARBAGE  COLLECTING 
ON  UNUSED  SETS. 

*) 
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PROCEDURE  MINUSP ( SI , S2 : SETS ;  VAR  RESULT : SETS ) ; 

(* 

RETURNS  A  NEW  SET  RESULT  WHOSE  VALUE  IS  THE 
SET-DIFFERENCE  OF  SETS  SI  AND  S2. 

*) 


FUNCTION  MINUS ( SI , S2 : SETS) :SETS; 

(* 

AME  AS  MINUSP  EXCEPT  THIS  IS  A  FUNCTION,  AND 
HENCE  HAS  NO  CONTROL  OF  GARBAGE  COLLECTING  ON 
UNUSED  SETS. 

*) 


PROCFOURE  ASSIGNSET ( S : SETS ;  VAR  RESULT : SETS )  ; 

(' 

RETURNS  A  NEW  SET  RESULT  WHOSE  VALUE  IS  SET 
S.  (CREATES  A  COPY  OF  S) . 

*) 


PROCEDURE  SETINSERT( ELEMENT: INTEGER;  SsSETS); 

(* 

INSERTS  ELEMENT  INTO  SET  S. 

*) 


FUNCTION  ISMEMBER( ELEMENT: INTEGER;  S : SETS ): BOOLEAN ; 

(* 

RETURNS  TRUE  <=»>  ELEMENT  IS  IN  SET  S. 

*> 


FUNCTION  ISSUBSET(S1, S2: SETS) : BOOLEAN; 

(* 

RETURNS  TRUE  <=>  SI  IS  A  SUBSET  OF  S2. 

*) 


FUNCTION  ISEQUAL(S1,  S2:  SETS)  -.BOOLEAN; 
(* 


*) 


RETURNS  TRUE  <=>  SET  SI  AND  SET  S2  CON¬ 
TAIN  THE  SAME  ELEMENTS. 
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PROCEDURE  UNPACKSET ( S : SETS ;  VAR  UNPtUNPSET); 

(* 

UNPACK  SET  S  INTO  ARRAY  UNP.  THE  ZEROETH 
ELEMENT  OF  UNP  IS  THE  NUMBER,  N,  OF  ELEMENTS 
IN  S.  THE  NEXT  N  ELEMENTS  IN  UNP  ARE  THE 
ELEMENT  VALUES  OF  S. 

*) 


PROCEDURE  WRITESET(VAR  F : TEXT ; S : SETS ;  INDrINTEGER; 

VAR  NUM : INTEGER) ; 

(* 

WRITE  SET  S  TO  FILE  F,  USING  NO  MORE  THAN 
130  CHARACTERS  PER  LINE.  START  EACH  NEW  LINE 
WITH  AN  INDENTATION  OF  IND  (IF  IND>0)  ELSE 
WITH  AN  INDENTATION  OF  5.  ALSO,  IF  IND=0 
THEN  PRECEED  FIRST  LINE  WITH  NUMBER  OF  OBJECTS 
IN  THE  SET.  RETURN  THE  NUMBER  OF  OBJECTS  IN 
THE  SET  IN  THE  OUTPUT  PARAMETER  NUM. 

*) 


B.2.2  Symbol  Routines 

PROCEDURE  SETS YMMAX ( S YM : SYMBOL ;  MAXATTR : INTEGER ) ; 

(  * 

SET  MAXIMUM  ATTRIBUTES  ALLOWED  BY  SYM  TO 
MAXATTR. 

*) 


FUNCTION  GETS YMMAX ( SYM : SYMBOL) : INTEGER ; 

(* 

RETURNS  MAXIMUM  NUMBER  OF  ATTRIBUTES  FOR  SYMBOL 
SYM  . 

*) 


PROCEDURE  SETSYMOBJ( SYM: SYMBOL;  OBJC : OBJCTCLASS ) ; 

(* 

SET  OBJECT-CLASS  FOR  SYMBOL  SYM  TO  BE  OBJC. 

*) 


FUNCTION  GETSYMOBJ( SYM: SYMBOL) : INTEGER; 

(* 

RETURN  OBJECT-CLASS  FOR  SYMBOL  SYM. 

(NOTE  -  RESULT  IS  INTEGER  SINCE  OBJCTCLASS 
CANNOT  HAVE  A  VALUE  OF  ZERO. ) 

*> 
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PROCEDURE  SETSYMAUX{SYM: SYMBOL; AUX: INTEGER; VAL: INTEGER) ; 
(* 

SET  AUXILIARY  ATTRIBUTE  AUX  OF  SYMBOL  SYM 
TO  VAL . 

*) 


FUNCTION  GETSYM AUX (SYM: SYMBOL; AUX; INTEGER ' : INTEGER; 

(* 

GET  AUXILIARY  ATTRIBUTE  AUX  OF  SYMBOL  SYM. 

*) 


FUNCTION  HASH ( VAR  STRrSYMREP;  LEN: SYMLNG; 

VAR  WASTHERE : BOOLEAN) : SYMBOL; 

(* 

HASH  STRING  STR  OF  LENGTH  LEN.  RETURN  SYMBOL 
POINTER  FOR  STRING.  IF  STRING  ALREADY  IN  SYMBOL 
TABLE  RETURN  ITS  PREDEFINED  HASHED  VALUE  AND 
SET  WASTHERE  TO  TRUE,  OTHERWISE  CREATE  AND 
RETURN  A  NEW  SYMBOL  POINTER  AND  SET  WASTHERE 
TO  FALSE. 

*) 


PROCEDURE  GETSTRING( SYM: SYMBOL; 

(* 


VAR  STR: SYM REP ; 

VAR  LEN: SYMLNG); 


*) 


GET  STRING  VALUE  <STR, LEN>  ASSOCIATED  WITH 
SYMBOL  SYM. 


PROCEDURE  WRITESYM ( VAR  F : TEXT ;  SYM: SYMBOL); 

(* 

WRITE  SYMBOL  SYM  TO  FILE  F. 

*) 


PROCEDURE  LISTSYMSET(VAR  F:TEXT;  S:SETS;  INDENT: INTEGER) ; 

(* 

WRITE  THE  SET  OF  SYMBOLS  IN  SET  S  TO  FILE  F 
USING  NO  MORE  THAN  130  CHARACTERS  PER  LINE. 

START  EACH  NEW  LINE  WITH  AN  INDENTATION  OF 
INDENT  SPACES. 

*) 


J 
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B.2.3  Symbol  Attribute  Routines 

PROCEDURE  SETSYMATT(SYM: SYMBOL?  ATT :ATTB LOCK) ; 

(* 

SET  ATTRIBUTE-FIELD  OF  SYMBOL  SYM  TO  ATT. 

*) 


FUNCTION  GETSYMATT(SYM : SYMBOL) rATTBLOCK? 

(* 

GET  ATTRIBUTE-FIELD  OF  SYMBOL  SYM. 

*) 


FUNCTION  NEWATTBLCK:  ATTBLOCK; 

(* 

RETURNS  A  NEW  ATTRIBUTE-BLOCK  POINTER  AND  UP¬ 
DATES  TOTAL  NUMBER  OF  ALLOCATED  POINTERS. 

*) 


PROCEDURE  SETATT( ATT: ATTRIBUTE;  SYMiSYMBOL;  VAL: INTEGER) ; 

(* 

IF  SYMBOL  SYM  HAS  ACCES  TO  ATTRIBUTE  ATT 
THEN  SET  ATTRIBUTE  ATT  OF  SYM  TO  VAL,  ELSE 
REPORT  ERROR. 

*) 


FUNCTION  GETATT( ATT: ATTRIBUTE;  SYM : SYMBOL) : INTEGER; 

(* 

GET  ATTRIBUTE  ATT  OF  SYMBOL  SYM  PROVIDED 
SYM  HAS  ACCESS  TO  THIS  ATTRIBUTE,  ELSE  REPORT 
ERROR. 

*) 


B.2.4  Object-Class  Routines 

FUNCTION  GETOBJSET ( OB JCL : OB JCTCLASS ) : SETS ; 

(* 

GET  THE  SET  OF  OBJECTS  ASSOCIATED  WITH  OBJECT 
CLASS  OB JCL. 

*) 


PROCEDURE  OBJCLDEBUG(VAR  F : TEXT ) ; 

<* 

DUMP  ALL  VALID  OBJECT-CLASSES  (INCLUDING  THEIR 
OBJECTS)  TO  FILE  F. 

*) 
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PROCEDURE  SETMAXATT ( OBJCL : OB JCTCLASS ;  VALs INTEGER) ; 

(* 

SET  MAXIMUM  NUMBER  OF  ATTRIBUTES  FOR  OBJECT- 
CLASS  OBJCL  TO  VAL. 

*> 


FUNCTION  GETMAXATT (OBJCL: OB JCTCLA SS ) : INTEGER; 

(* 

RETURN  MAXIMUM  NUMBER  OF  ATTRIBUTES  FOR 
OBJECT-CLASS  OBJCL* 

*) 


PROCEDURE  INCLUDE ( OBJ : OBJECT ;  OBJCL : OB JCTCLASS ) ; 

(* 

INCLUDE  OBJECT  OBJ  INTO  OBJECT-CLASS  OBJCL. 

*) 


FUNCTION  INCLASS (OBJ: OBJECT;  OBJCL : OB JCTCLASS ) :  BOOLEAN; 
(* 

RETURNS  TRUE  <=>  OBJECT  OBJ  IS  IN  OBJECT- 
CLASS  OBJCL. 

*) 


B.2.5  Packet  Routines 

PROCEDURE  SETACT ION (ACTN: ACTION;  P: PACKET;  S:SETS); 

(* 

SET  SPECIFIED  ACTION  OF  PACKET  P  TO  BE  SET  S. 

*) 


FUNCTION  GETACT ION ( ACTN : ACT ION ;  P : PACKET ) : SETS ; 

<* 

GET  ACTION  ACTN  FROM  PACKET  P. 

*) 


B.2.5.1  Use-Table  Routines 

PROCEDURE  SETPCKPLST{P: PACKET;  VAL: INTEGER) ; 

(* 

SET  PARAM-LIST  OF  PACKET  P  TO  VAL. 

*) 


FUNCTION  GETPCKPLST( P: PACKET) : INTEGER; 
(* 

GET  PARAM-LIST  OF  PACKET  P. 

*) 
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PROCEDURE  SETPCKNAME ( P : PACKET ;  VAL : SYMBOL ) ; 

(* 

SET  REFERENCED  SUBPROG  OF  PACKET  P  TO  VAL. 

*) 


FUNCTION  GETPCKNAME(P: PACKET) : SYMBOL; 

(* 

GET  REFERENCED  SUBPROG  OF  PACKET  P. 

*> 


PROCEDURE  SETPCKEDGE(P: PACKET;  VAL: PACKET); 

(* 

SET  USE-EDGE  OF  PACKET  P  TO  VAL. 

*) 


FUNCTION  GETPCKEDGE ( P : PACKET ) : PACKET ; 
(* 

GET  USE-EDGE  OF  PACKET  P. 

*) 


PROCEDURE  SETPCKNPRM(P: PACKET;  VAL: INTEGER) ; 

(* 

SET  NUMBER  OF  ACTUAL  PARAMS  OF  PACKET  P  TO 
VAL. 

*) 


FUNCTION  GETPCKMPRM(P: PACKET) : INTEGER; 

(* 

GET  NUMBER  OF  ACTUAL  PARAMS  OF  PACKET  P. 

*) 


PROCEDURE  SETPCKREF(P: PACKET;  VAL: INTEGER) ; 

(* 

SET  CODE-REFERENCE  OF  PACKET  P  TO  VAL. 

*) 


FUNCTION  GETPCKREF <  P : PACKET ) : INTEGER ; 

(* 

GET  CODE -REFERENCE  OF  PACKET  P. 

*) 


FUNCTION  NEWPACKET: PACKET; 

(* 

RETURN  A  NEW  PACKET  FROM  THE  PACKET-POOL. 

*) 
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B.2.5.2  Flowgraph  Routines 

FUNCTION  NEWFGNNODE : FGNODE ; 

(* 

RETURN  A  NEW  FLOWGRAPH  NODE  FROM  PACKET  POOL. 

*) 


PROCEDURE  SETFGNTYP(F: FGNODE?  VAL: INTEGER) ; 

(* 

SET  TYPE  OF  FLOWGRAPH  NODE  F  TO  VAL. 

*) 


FUNCT ION  GETFGNTYP ( F : FGNODE ) : INTEGER ; 

(* 

GET  TYPE  OF  FLOWGRAPH  NODE  F. 

*) 


PROCEDURE  SETFGNEXP(F: FGNODE;  E : PACKET) ? 

(* 

SET  EXPRESSION  TREE  ATTRIBUTE  OF  FLOWGRAPH  NODE 
F  TO  E. 

*) 


FUNCTION  GETFGNEXP{ F : FGNODE ) ; PACKET ; 

(* 

GET  EXPRESSION  TREE  FOR  FLOWGRAPH  NODE  F. 

*) 


PROCEDURE  SETFGNNSON ( F : FGNODE ;  VAL: INTEGER) ; 

(* 

SET  NUMBER  OF  SON-EDGES  OF  FLOWGRAPH  NODE  F 
TO  VAL . 

*> 


FUNCTION  GETFGNNSON(F: FGNODE) : INTEGER; 

(* 

GET  NUMBER  OF  SON-EDGES  FOR  FLOWGRAPH  NODE  F. 

*) 


PROCEDURE  SETFGNNPAR(F: FGNODE;  VAL: INTEGER) ? 

(* 

SET  NUMBER  OF  PARENT-EDGES  OF  FLOWGRAPH  NODE  F 
TO  VAL. 
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FUNCTION  GETFGNNPAR( F : FGNODE ) : INTEGER; 

(* 

GET  NUMBER  OF  PARENT-EDGES  FOR  FLOWGRAPH  NODE  F. 

*) 


PROCEDURE  SETFGNSON(F: FGNODE;  VAL: SETS); 

(* 

SET  SON-EDGES  OF  FLOWGRAPH  NODE  F  TO  VAL. 

*) 


FUNCTION  GETFGNSON { F : FGNODE ) : SETS ; 

(* 

GET  SON-EDGES  FOR  FLOWGRAPH  NODE  F. 

M 


PROCEDURE  SETFGNPAR(F; FGNODE;  VAL: SETS); 

(* 

SET  PARENT-EDGES  OF  FLOWGRAPH  NODE  F  TO  VAL. 

*) 


FUNCTION  GETFGNPAR(F: FGNODE)  -.SETS; 

(* 

GET  PARENT-EDGES  FOR  FLOWGRAPH  NODE  F. 

*> 


PROCEDURE  NNEDGE ( FROMNODE , TONODE : FGNODE ) ; 

(* 

CREATE  A  FLOWGRAPH  EDGE  FROM  NODE  FROMNODE 
TO  NODE  TONODE. 

*) 


PROCEDURE  NSEDGE( FROMNODE; FGNODE;  TOSET:SETS)> 

(* 

CREATE  A  FLOWGRAPH  EDGE  FROM  NODE  FROMNODE 
TO  EVERY  NODE  IN  SET  TOSET. 

*) 


PROCEDURE  SNEDGE ( FROMSET ; SETS ;  TONODE : FGNODE ) ; 

(* 

CREATE  A  FLOWGRAPH  EDGE  FROM  EVERY  NODE  IN  SET 
FROMSET  TO  NODE  TONODE. 

*) 
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PROCEDURE  SSEDGE ( FROMSET,  TOSET: SETS) ; 

(* 

CREATE  A  FLOWGRAPH  EDGE  FROM  EVERY  NODE  IN  SET 
FROMSET  TO  EVERY  NODE  IN  SET  TOSET. 

*> 


B.2.5.3  Expression-Tree  Routines 

FUNCTION  NEWEXPNODE : EXPNODE ; 

(* 

RETURN  A  NEW  EXPRESSION-TREE  NODE  FROM  THE 
PACKET  POOL. 

*> 


PROCEDURE  SETEXPTYP(E: EXPNODE;  TYP: INTEGER) ; 

(* 

SET  TYPE  OF  EXPRESSION-TREE  NODE  E  TO  TYP. 

*) 


FUNCTION  GETEXPTYP(E: EXPNODE) : INTEGER; 

(* 

GET  TYPE  OF  EXPRESSION-TREE  NODE  E. 

*) 


PROCEDURE  SETEXPSON( I ; INTEGER;  E : EXPNODE ;  VAL: INTEGER) ; 

(* 

SET  THE  T.TH  SON  OF  EXPRESSION-TREE  NODE  E  TO 
VAL. 

*) 


FUNCTION  GETEXPSON( I ; INTEGER;  E ! EXPNODE ) J INTEGER; 

<* 

GET  THE  ITH  SON  OF  EXPRESSION-TREE  NODE  E. 

*) 


PROCEDURE  SETEXPUSE(E; EXPNODE;  VALs INTEGER) ; 

(* 

SET  USE-LINK  FIELD  OF  EXPRESSION-TREE  NODE  E 
TO  VAL. 

*) 


FUNCTION  GETEXPUSE(E : EXPNODE ) s INTEGER; 

<* 

GET  USE-LINK  OF  EXPRESSION-TREE  NODE  E. 

*) 
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PROCEDURE  SETEXPOBJ { E : EXPNODE ;  VAL: INTEGER ) ; 

(* 

SET  OBJECT  FIELD  OF  EXPRESSION-TREE  NODE  E  TO 
VAL. 

*) 


FUNCTION  GETEXPOBJ ( E : EXPNODE ) : INTEGER ; 

(* 

GET  OBJECT  OF  EXPRESSION-TREE  NODE  E- 

*) 


B.2.6  Parameter  Building  Routines 

FUNCTION  NEWFPNODE:  FPRMPTR; 

(* 

RETURN  NEW  FORMAL-PARAMETER  NODE. 

*) 


PROCEDURE  SETFPUSE(FP: FPRMPTR;  L: INTEGER) ; 

(* 

SET  USE-LINK  OF  PARAMETER  NODE  FP  TO  L. 

*) 


FUNCTION  GETFPUSE ( FP ; FPRMPTR ) : INTEGER ; 

(* 

GET  USE-LINK  OF  PARAMETER  NODE  FP. 

*) 


PROCEDURE  SETFPLINK(FP: FPRMPTR;  L: INTEGER); 

<* 

SET  FP-LINK  OF  PARAMETER  NODE  FP  TO  L. 

*) 


FUNCTION  GETFPLINK ( FP ; FPRMPTR) : INTEGER ; 

(* 

GET  FP-LINK  OF  PARAMETER  NODE  FP. 

*) 


PROCEDURE  SETFPSET(FP: FPRMPTR;  L:SETS); 

(* 

SET  GLOBAL  SET  OF  PARAMETER  NODE  FP  TO  L. 

*) 
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FUNCTION  GETFPSET ( FP : FPRMPTR) : SETS r 
(* 

GET  GLOBAL  SET  OF  PARAMETER  NODE  FP. 

*) 


B.2.7  Caligraph  Routines 

FUNCTION  NEWCGRNODE ; CALLPTR ; 

(* 

RETURN  A  NEW  CALLGRAPH  POINTER 

*) 


PROCEDURE  SETCGRNAME ( C : CALLPTR ;  VAL: SYMBOL); 

(* 

SET  NAME-FIELD  OF  CALLGRAPH  NODE  C  TO 

*) 


FUNCTION  GETCGRNAME ( C : CALLPTR) : SYMBOL; 

(* 

GET  NAME-FIELD  OF  CALLGRAPH  NODE  C. 

*> 


PROCEDURE  SETCGRNMFP ( C : CALLPTR ;  VAL: INTEGER) ; 
(* 

SET  NUM-PARAM-FIELD  OF  CALLGRAPH  NODE 
VAL. 

*) 


FUNCTION  GETCGRNMFP ( C : CALLPTR) : INTEGER; 

(* 

GET  NUM-PARAM-FIELD  OF  CALLGRAPH  NODE 

*) 


PROCEDURE  SETCGRFPL(C: CALLPTR;  VAL: INTEGER) ; 

(* 

SET  FP-FIELD  OF  CALLGRAPH  NODE  C  TO 

*) 


FUNCT ION  GETCGRFPL ( C : CALLPTR ) : INTEGER ; 

<* 

GET  FP-FIELD  OF  CALLGRAPH  NODE  C. 

*) 


VAL. 


C  TO 


C. 


VAL. 


* _ l .. 
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PROCEDURE  SETCGREDGE ( C : CALLPTR;  VAL: PACKET) ; 

(* 

SET  EDGE-FIELD  OF  CALLGRAPH  NODE  C  TO  VAL. 

*) 


FUNCTION  GETCGREDGE ( C :CALLPTR) : PACKET; 

(* 

GET  EDGE-FIELD  OF  CALLGRAPH  NODE  C. 

*) 


PROCEDURE  SETCGRNTRY ( C ; CALLPTR ;  VAL: PACKET) ; 

(* 

SET  ENTRY-FIELD  OF  CALLGRAPH  NODE  C  TO  VAL. 

*) 


FUNCTION  GETCGRNTRY(C: CALLPTR) : PACKET; 

(* 

GET  ENTRY-FIELD  OF  CALLGRAPH  NODE  C. 

*) 


PROCEDURE  SETCGREXIT(C -.CALLPTR;  VAL: PACKET)  ; 

(* 

SET  EXIT-FIELD  OF  CALLGRAPH  NODE  C  TO  VAL. 

*) 


FUNCTION  GETCGREXIT(C :CALLPTR) : PACKET; 

(* 

GET  EXIT-FIELD  OF  CALLGRAPH  NODE  C. 

*) 


PROCEDURE  SETMAI NCALL( VAL: CALLPTR ) ; 

(* 

SET  MAIN  PROGRAM  INDICATOR  TO  BE  CALLGRAPH 
NODE  C . 

*> 


FUNCTION  C ALLEDGE ( C : CALLPTR ;  OBJ: SYMBOL; 

NUMPARAM: INTEGER) : PACKET; 

<* 

SEARCH  USE-EDGES  OF  CALLGRAPH  ENTRY  C  FOR  A 
PACKET  WITH  NAME-FIELD  OBJ,  AND  RETURN  PACKET. 
IF  PACKET  DOESNT  EXIST,  THEN  CREATE  A  PACKET 
WITH  NAME  OBJ. 

*) 
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B.2.8  Parse-Tree  Routines 

FUNCTION  GETPRSATT(PND:  PARSENODE  ,*  SEL :  PRSSELECT)  :  INTEGER? 

<* 

GET  SELECTED  FIELD  FROM  PARSE-TREE  NODE  #PND# . 

*) 


PROCEDURE  SETPRSATT( PND: PARSENODE;  SEL : PRSSELECT ; 

VAL: INTEGER) ; 

(* 

SETS  THE  SELECTED  FIELD  OF  PARSE-TREE  NODE 
"PND"  TO  VAL. 

*) 


PROCEDURE  TREEDUMP ( VAR  F : TEXT ) ? 

(* 

DUMP  OF  PARSE  TREE  IN  TREE  REPRESENTATION. 

*> 


B.2.9  Other  Routines 

These  include  all  the  standard  routines  provided  by  the 
PASCAL  Report  ([Jensen  74,  Appendix  A]). 
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Output  Tables  Format 


C.l  Data  Structure  Representations 


CNAME 


CEPGE 


CEN  l'I’Y 


CNUMFP 


CFIRSTFP 


SYMBOL  pointer  to  name  of  program-unit. 

PACKET  pointer  to  first  use-table  node 
in  edge-list. 

PACKET  pointer  to  ENTRY  flowgraph  node 
for  this  program-unit. 

Number  of  formal  parameters  for 
program-unit . 

SET  pointer  to  first  formal  parameter 
node . 


Figure  C.l  Callgraph  Node  Structure 


INOBJ 

1 

1 

FOBJ 

1 

NOBJ  is  the  number  of  objects  in 
action-class  ,  and  FOBJ  is  a  SET 
pointer  for  the  first  object. 

1  - 

INOBJ 

1 

1 

FOBJ 

1 

1 

1  NOB  J 

1 

FOBJ 

1 

Figure  C.2  Action  Packet  Structure 


I  MODE 

| - 

I  LINK 


Parameter-mode  indicator  (1  =>  "IN", 
2  =>  "OUT",  3  =>  "IN/OUT"). 
FP-pointer  link  to  next  parameter. 


Figure  C.3  Fp-Node  Structure 
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PACKETS 


FNODETYPE 


FEXPTR 


FNSON 


FFSON 


FNPAR 


FFPAR 


Flowgraph  node-type  indicator. 

PACKET  pointer  to  expression- tree 
for  this  node. 

Number  of  sons  for  this  node. 


PACKET  pointer  to  first  son. 
Number  of  parents  for  this  node. 


PACKET  pointer  to  first  parent. 


ACTIONS 


J 


root 


_ igure  C.4  Flowgraph  Node  Structure 


ENODETYPE 


ES0N1 


ES0N2 


EUSE 


EOBJ 


(unused) 


Expression-tree  node-type  indicator. 

PACKET  pointer  to  first  son. 

PACKET  pointer  to  second  son. 

PACKET  pointer  to  link  use-table 
information . 

Symbol  pointer  to  object  whose  action 
is  currently  unknown. 


}  ACTIONS 


Figure  C.5  Expression-Tree  Node  Structure 
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Number  of  parameters  in  an  invocation 
of  this  pr ogr am-uni t . 

FP  pointer  to  first  ac+iual -parameter 
node . 

SYMBOL  pointer  to  name  oi  program-unit. 


PACKET  pointer  to  first  expression-tree 
node  for  call  to  this  program-unit. 
PACKET  pointer  to  next  entry  in  use- 
table  . 

^  ACTIONS 


Figure  C.6  Use-Table  Node  Structure 


UNPARAM 


UPLIST 

UNAME 


UCODEREF 

ULINK 

(unused) 
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Pages  61  and  62  represent  the  format  for  the  output  Tables  File. 
This  file  is  a  text  file  composed  of  lines  (records).  Each  line  holds 
no  more  than  130  characters.  Below  is  a  line-by-line  description  of 
the  information  on  those  pages. 

Notice  that  lines  12,  17,  18,  19,  20,  22,  23,  24  and  the  ends  of 
lines  13  and  14  describe  sets  or  1 ists  of  objects.  Such  descriptions 
are  represented  by  (1)  the  number,  n,  of  objects  in  the  list,  and  (2) 
a  list  of  the  n  objects.  The  list  may  extend  over  a  line  boundary. 
After  the  last  object  in  a  given  list  is  printed  (within  the  file), 
the  line  holding  that  object  is  terminated. 


lire  1 
lines  2,3 

line  4 

lines  5,6 

line  7 
lines  8,9 


line  10 


n  is  the  number  of  user-defined  actions. 

3l 

Action  names.  Each  string  is  exactly  10  characters  long 
and  each  begins  in  column  2  of  a  new  line. 

n^  is  the  number  of  express  ion-tree  plus  flowgraph  node 

types . 

Node-type  names.  Each  string  is  exactly  10  characters 
long  and  each  begins  in  column  2  of  a  new  line. 

ns  is  the  number  of  Symbol  Table  entries  (symbols). 

Symbols,  length.,  is  the  number  of  characters  in  string^. 

att^  is  the  Attribute  Table  descriptor  owned  by  symbol^. 

There  is  exactly  one  blank  between  att..  and  string^. 

Number  of  callgraph  nodes,  and  callgraph  node  descriptor 
(index)  for  the  main  program. 


lines  11-32  Describe  all  information  for  callgraph  node  1. 


line  11  Information  for  callgraph  node  1.  See  Figure  C.l. 

line  12  Information  for  callgraph  node  1.  See  Figures  C.l  and  C.3. 


lines  13-15  Describe  all  use-table  information  for  callgraph  node  1. 


line  13  Information  for  use-table  node  indexed  by  UNODE.  .  of 

A  »  1 

callgraph  node  1.  See  Figure  C.6. 

line  14  Information  for  use-table  node  indexed  by  UNODE,  „  of 

l.n 

callgraph  node  1.  See  Figure  C.6. 

NOTE:  The  value  for  ULINK.  is  UNODE. +y 

line  15  Zero.  Indicates  end-of-use-table  information  for  callgraph 
node  1. 


lines  16-25  Describe  all  flowgraph  information  for  flowgraph  owned 
by  callgraph  node  1. 
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line  16 

line  17 
line  18 

line  19 

line  20 

lires  21-24 

line  25 
lines  26-32 
line  26 

lines  27,28 

lines  29-31 

line  32 

lines  33-34 

lines  35-36 


Information  for  flowgraph  node  indexed  by  FNODE,  ,  of 

i  »  1 

callgraph  node  1.  See  Figure  C.4. 

Set  of  sons  for  flowgraph  node  FNODE^  ^  of  callgraph  node  1. 

Set  of  parents  for  flowgraph  noae  FNODE ,  ,  of  callgraph 
node  1. 

Set  of  objects  in  Action-Class^  for  flowgraph  node  FNODEj  ^ 
of  callgraph  node  1. 

Set  of  objects  in  Action-Class,,  (n.  given  in  line  1)  for 

na  a 

flowgraph  node  FNODEj  ^  of  callgraph  node  1. 

Same  as  lines  16-20  except  for  flowgraph  node  indexed  by 
FNODEi  m.  The  total  number  of  flowgraph  nodes,  m,  is 

indeterminate. 

Zero.  Indicates  end-of-flowgraph  information  for  callgraph 
node  1. 

Describe  all  express ion- tree  information  for  callgraph 
node  1 . 

Information  for  express ion -tree  node  indexed  by  ENODEj  j 
of  callgraph  node  1.  See  F^jure  C.5. 

Action  sets  (format  as  in  lines  19,  20)  for  expression-tree 
node  ENODEj  j  of  callgraph  node  1. 

Same  as  lines  26-28  except  for  expression-tree  node  ENODEj  k 

of  callgraph  node  1.  The  total  number  of  expression-tree 
nodes,  k,  is  indeterminate. 

Zero.  Indicates  end-of-expression-tree  information  for 
callgraph  node  1. 

Represent  same  information  as  lines  11-32  except  for 
callgraph  node  2. 

Represent  same  information  as  lines  11-32  except  for 
callgraph  node  numcall ,  where  numcall  is  given  in  line  10. 
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1.  ri 

O 

2.  strinc 


3.  strinc 

4.  nt 

5.  strinc 


6.  string^ 

7.  ^ 

8.  lengthy  att^  string^ 


9.  lengthn  attn  string^ 

10.  numcall  ma incall 

11.  CNAMEj  CEDGE1  CENTRY^  CEXITj 

12.  CNUMFPj  MODEj  j  MODEj  2  ...  MODEj  CNUMFP 

13.  UN0DE1  1  UNAME1  j  UCODEREFj  j  UNPARAMj  j  P^j  j 


•  -l.l.UNPARAMj  j 


14.  UNODE,  UNAME,  _  UCODEREF,  _  UNPARAM,  _  P,  _  , 

- — l,n  - l,n  - l,n  - l,n  — l,n,l 

15.  0 

16.  FNODEj  j  FNOOETYPEj  j  FEXPTRj  j 

17.  FNSONj^  SONj^j^  ...  SONj f j >FNS0Ni  ^ 

18.  FNPARj^  PAR i tit\  •••  £Mifi,FNPARj  1 

19.  NQMj t j t j  ^ll,  1,1,1  ^1,1,1,M0BJ1>1(1 


£-l,n, UNPARAMj 


20.  NOBJ,  ,  _  OBJ,  ,  _  ,  ...  OBJ,  ,  _  iini)1 

- 1,1, na  - l,l,na,l  - 1‘1*na’N0BJl,l,n 


21. 

FNODE, 
- 1  ,m 

FNODETYPE,  _ 
- 1  ,m 

FEXPTR,  .. 

- — l  ,m 

22. 

FNSON,  _ 
- 1  ,m 

SON,  ,  . . . 
- l,m,l 

— l,m, FNSON 

23. 

NOBJ,  m  , 
l,m,l 

OBJ,  ,  . 
- l,m,l,l 

. . .  OBJ,  , 
- 1 ,m,l 

24. 

NOBJ,  m  „ 
1  ,m,n 

OBJ,  m  *  1 
a  1 *m,na ’ 1 

. . .  OBJ, 

— l  ,m,n 

I 

1  ,m,l 


25.  0 
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26.  ENODE1  1  ENODETVPE1  1 

27-NOBJum  OMia.Ul 


ESONl1  J  E$ON21  J  EUSE1  j  EOBJj  j 
•*'  — l.l.l.NOBJj  j  j 


28.  NOBJ,  ,  n  OBJ,  ,  n  ,  . 
- 1,1, n  - l.l.n  ,1 


.  .  OBJ 


l,l,n  .NOBJ.  . 


29.  ENODE1  k  EN00ETYPE1  k  ESON^  k  ESON2j  EUSE1  k  EOBJj  k 


30.  NOBJljkjl  OBJ_i , k ,  1 , 1 


.  OBJ 


■l,kfl,NOBJ1>k  j 


31.  NOBJ,  .  „  OBJ,  .  „  ....  OBJ 
- l,k,n - l,k,n  ,1  - 

a  a 


l,k.na.H°M1#|c 


32.  0 

33.  CNAME2  CEDGEq  CENTRY2  CEXITq 


34.  0  ’ 


35*  Humean  ^umcall  ™*^umcall  ^umcall 
•  •  •  • 

•  •  •  • 

36.  0  * 
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SAM/ SAL  System  Sample  Program 


This  appendix  presents  an  example  of  the  various  inputs 
to  and  outputs  from  the  SAM/SAL  system.  The  language  speci¬ 
fied  by  this  example  is  TURINGOL,  a  simple  language 
described  in  [Knuth  68]. 

Section  D.l  lists  a  SAL  program  specifying  TURINGOL.  This 
listing  corresponds  to  "SAL  Program  S"  in  Figure 
1.1. 

Section  D.2  lists  a  sample  TURINGOL  program.  This  program 
corresponds  to  the  "User  Program  U"  in  Figure 
1.1. 

Section  D.3  lists  the  "Output  Report"  in  Figure  1.1  for  the 
sample  program  of  Section  D.2. 

Section  D.4  lists  the  "Annotated  Flowgraphs"  file  in  Figure 
1.1  for  the  sample  program  of  Section  D.2.  This 
file  is  the  Tables  File  whose  general  format  is 
given  in  Section  C.2. 

Section  D.5  presents  a  user-readable  listing  of  the  Tables 
File  of  Section  D.4. 

Section  D.6  gives  a  graphic  illustration  of  the  output  for 
the  sample  program  of  Section  D.2. 

Note  that  TURINGOL  allows  no  procedures  or  functions. 
As  a  result,  (1)  the  output  Tables  File  will  always  consist 
of  a  callgraph  having  only  a  single  node;  (2)  the  use-table 
list  (dependent  sons  of  a  callgraph  node)  will  be  empty;  and 
(3)  no  expression  trees  are  necessary.  These  properties  are 
apparent  from  the  listing  in  Section  D.5. 
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D. 1  TURINGOL:  A  SAL  Program 


SALTRAN  (VERSION:  02/17/01)  OATE:  61/03/05. 


TIME'.  11  07.31 


1 

2 

3 

4 

5 

6 

7 

8 
9 


O 

0 

o 

0 

0 

0 

0 

0 

0 


PROGRAM  TURINGOL; 

* 

TURINGOL  IS  A  SAMPLE  LANGUAGE  SPECIFIED  IN: 


* 

<1 

II 

» 

n 

n 

» 


KNUTH.  D.  E  ..'•SEMANTICS  OF  CONTEXT-FREE  LANGUAGES**,  MATHEMATICAL 
SYSTEMS  THEORY,  VOL.  2,  NO.  2.  (JUNE  1968),  PP .  127-145. 

INSTEAD  OF  TUR l NG -MACH  I NE  DELTA  FUNCTIONS.  THIS  SPECIFICATION 
PRODUCES  AN  ANNOTATED  FLOWGRAPH. 


10 

O 

« 

1 1 

0 

II  SINCE  THIS 

IMPLEMENTATION  CANNOT  HANDLE  THE  EMPTY  PRODUCTION, 

12 

0 

*  ’’HE  EMPTY  STATEMENT 

MILL  BE  DENOTED 

BY  "NULL". 

13 

0 

It 

14 

0 

15 

0 

PREAMBLE 

16 

0 

17 

0 

SCANNER  SCANTOK: 

18 

0 

SCANTOK 

-  > 

(SPACES  /  TOKEN >«  SPACES; 

19 

0 

SPACES 

-  > 

(  •  1  / 

• EOL ' ) «  ; 

20 

0 

SCANNER 

TOKEN: 

21 

0 

TOKEN 

-  > 

IONT  / 

STRNG 

/  LITERAL 

/  Ml  SCI  /  MISC2 

22 

0 

END  TOKEN; 

23 

0 

I  DNT 

-  > 

CHAR* 

*>  "IDNTFR”  ; 

24 

0 

STRNG 

-  > 

CHAR* 

=  >  "STRING".  ; 

25 

o 

literal 

-  > 

..  ..  , 

..  ..  ,  .....  /  ..... 

/  "t"  / 

"SINGLE"  ; 

26 

0 

CHAR 

-  > 

"A"  / 

"B“  /  "C"  /  "D” 

/  /  "F" 

/ 

27 

0 

"G"  / 

"H"  /  “I"  /  "J" 

/  l."  /  "L" 

/ 

28 

0 

•M”  / 

"N“  /  “O"  /  "P” 

/  "O"  /  "R" 

/ 

29 

0 

“S'  / 

" T“  /  “U"  /  “V" 

/  "W"  /  -X1 

/ 

30 

0 

“Y"  / 

“2"  ; 

31 

0 

MI  SC  1 

-  > 

"«?•'  = 

>  "CNSTNT"; 

32 

0 

MISC2 

-  > 

"»S"  = 

>  "FLOAT”; 

33 

0 

ENO  SCANTOK. 

34 

0 

35 

0 

END  PREAMBLE 
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SALTRAN  (VERSION:  02/17/81) 


36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 


DATE:  81/03/05. 


TIME:  1107.31 
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0 

O 

0 

0 

O 

0 

O 

0 

O 

O 

O 

O 

0 

0 

0 

0 


DECLARATIONS 

OBJECT  CLASSES  : 
ALPHABET  :  (  1 ; 

LABELS  ( FN 

ACTIONS  ■ 

DECLARE,  REF 
USE,  OEF 


FONODE) ; 


ON  ALPHABET; 
ON  LABELS; 


Fi-OWGRAPH  NODE  TYPES  : 

FNTRYSTMT,  EXITSTMT,  IFSTMT,  EMPTYSTMT . 
GOTOSTMT,  MOVESTMT,  PRINTSTMT; 

S  PROCEDURES  AND  FUNCTIONS 
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SALTRAN  (VERSION.  02/17/61)  DATE:  61/03/05.  TIME:  11.07.31. 


52 

0 

53 

0 

FUNCTION  SETLABEL! L: OBJECT;  S : FGNODE ) : 1 NTE6ER ; 

54 

0 

(  * 

55 

0 

SET  FLOWGRAPH  NODE  FOR  LABEL  L  TO  BE  S. 

56 

0 

*  ) 

57 

0 

BEGIN  *  SETLABEL  *) 

56 

1 

SETATT ( FN,  L,  S); 

59 

1 

SETLABEL: «1 

60 

1 

ENO  ( *  SETLABEL  * ) ; 

61 

0 

62 

0 

FUNCTION  GETLABEL! L: OBJECT;  CONTROL  1 NTEGER >: FGNODE ; 

63 

0 

(  « 

64 

0 

GET  FLOWGRAPH  NODE  ASSOCIATED  WITH  LABEL  L. 

65 

0 

»  ) 

66 

0 

BEGIN  («  GETLABEL  ») 

67 

1 

GETLABEL: =GETATT(FN,  L) 

68 

1 

ENO  (■  GETLABEL  *1; 

69 

0 

70 

0 

PROCEDURE  CHECKVAR( OBJ: OBJECT;  TOKEN : 1 NTEGER > ; 

71 

0 

(  * 

72 

0 

REPORT  SEMANTIC  ERROR  IF  OBJ  HAS  NOT  BEEN  DECLARED 

73 

0 

TO  BE  IN  THE  TAPE  ALPHABET. 

74 

0 

»  ) 

75 

0 

BEGIN  (*  CHECKVAR  ») 

76 

1 

IF  NOT  1NCLASSI OBJ .ALPHABET)  THEN 

77 

1 

BEGIN  (*  THEN  «> 

76 

2 

WRITELN; 

79 

2 

WRITELN!"  ": 10, "SEMANTIC  ERROR:"), 

60 

2 

WRITE! ”  20, "SYMBOL  " ) ; 

81 

2 

WR 1 TESYM ( OUTPUT , OBJ ) ; 

82 

2 

WRI  TELN(  ••  AT  TOKEN  “  ,  TOKEN :  1  ,  "  NOT  DECLARED.  “  ) 

83 

2 

END  (*  THEN  *) 

64 

1 

END  ( «  CHECKVAR  « ) ; 

85 

0 

66 

0 

PROCEDURE  CHECKLABEL (OBJ: OBJECT;  TOKEN: I NTEGER) ; 

87 

0 

!* 

68 

0 

REPORT  SEMANTIC  ERROR  IF  OBJ  HAS  NOT  BEEN  DEFINED 

89 

0 

AS  A  LABEL. 

90 

o 

«  ) 

91 

o 

BEGIN  («  CHECKLABEL  «> 

92 

1 

IF  NOT  1NCLASSI OBJ, LABELS)  THEN 

93 

1 

BEGIN  («  THEN  *) 

94 

2 

1 NCLUDE ( OB J , LABELS ) ; 

95 

2 

WRITELN; 

96 

2 

WRITELNC'  ” : 10. "SEMANTIC  ERROR:"); 

97 

2 

WRI  TEC’  20, "LABEL  ”  ) ; 

96 

2 

WRI TESYM (OUTPUT, OBJ ) ; 

99 

2 

WRITELN!"  AT  TOKEN  ".TOKEN: 1,"  NOT  DEFINED.") 

100 

2 

END  («  THEN  «) 

101 

1 

END  ( *  CHECKLABEL  « 1 ; 

102 

0 

103 

0 

FUNCTION  MAKEMAIN: SYMBOL, 

104 

0 

(  ■ 

105 

0 

CREATE  THE  SYMBOL  "TURINOOL"  AND  RETURN  ITS  DESCRIPTOR. 

106 

0 

*) 

107 

0 

VAR 

108 

0 

WASTHERE  :  BOOLEAN; 

109 

0 

REP  :  SYMREP; 

PAGE  3 


SALTRAN  (VERSION.  02/17/81)  DATE:  61/03/05.  TIME:  11  07.32. 

110  0  STR  :  UNPSTR; 

111  0  I  :  INTEGER; 

112  0  BEGIN  <«  MAKEMAIN  «); 

113  1  STRt 1 3 : «"T“ ; 

114  1  STR 12) : = ”U" ; 

115  1  STRt3) : *”R" ; 

116  1  STRC4) :  =" I “ ; 

117  1  STRI53 : *"N" ; 

118  1  STRC6) : * “G” ; 

119  1  STR  1 7 )  '•  *  "  O”  ; 

120  1  STRC8) : =“L" ; 

121  1  FOR  I : =9  TO  MAXCHAR  DO 

122  1  STRt I ) : *“ 

123  1  PACK ( STR , 1 , REP ) ; 

124  1  MAKEMAIN: sHASH (REP, 8, WASTHERE) 

125  1  END  («  MAKEMAIN  «); 
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END  DECLARATIONS 


SALTRAN  (VERSION:  02/17/81)  DATE:  81/03/05.  TIME:  11.07.32. 


LANGUAGE  SPECIFICATIONS 

GRAMMAR  ATTRIBUTES 

< PROGRAM >  : 

ENTRY,  EXIT  :  FGNODE; 

CALLNODE  :  CALLPTR; 

<STMT  LI ST>  : 

START  :  FGNODE; 

FINISH  :  SET  OF  FGNODE; 
LABELREF,  LABELDEF  :  INTEGER; 

<STATEMENT>  : 

START  :  FGNODE; 

FINISH  :  SET  OF  FGNODE; 
LABELREF,  LABELOEF  :  INTEGER; 


PAGE  S 


<01 RECTION>  :  ; 

< I F  PART>  :  ; 

<  OECLARAT I ON>  :  ; 

< I  DENT  I  FI ER>  : 

VALUE  :  SYMBOL; 
TOKEN  :  INTEGER; 


<STRI NG> 
VALUE 
TOKEN 


SYMBOL ; 
INTEGER; 


< EMPTY > 


END  GRAMMAR  ATTRIBUTES 


69 


W 


Appendix  0 


SALTRAN  (VERSION:  02/17/81)  DATE:  81/03/05.  TIME:  11.07.32. 
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164  0 

165  O 

166  1 

167  1 

168  1 

169  1 

170  1 

171  1 

172  1 

173  1 

174  1 

175  1 

176  1 

177  1 

178  1 

179  1 

180  1 
181  1 
182  1 

183  1 

184  1 

185  1 

186  1 

187  1 

188  1 

189  1 

190  1 

191  1 

192  2 

193  2 

194  2 

195  2 

196  2 

197  2 

198  2 

199  2 

200  2 
201  2 
202  2 

203  3 

204  3 

205  3 

206  3 

207  3 

208  3 

209  3 

210  3 

21  1  3 

212  3 

213  3 

214  3 

215  3 

216  3 

217  4 

218  4 

219  4 

220  4 

221  4 


RULES 

< PROGRAMS  : .=  <DECLARAT I 0N>  <STMT  LISTS 

SEMANTICS 

FLOWGRAPH  SPECIFICATIONS 

^PROGRAMS . ENTRY  :«  NEWFGNNOOE; 

< PROGRAM s . EX  1 T  :*  NEWFGNNODE; 

< PROGRAM >. CALLNODE  ■ =  NEWCGRNODE; 

STMT  LISTs.LABELREF  :«  <STMT  L I STs . LABELDEF; 

SETFGNTYPI < PROGRAMS . ENTRY,  ENTRYSTMT) ; 

SETFGNTYP< < PROGRAMS .EXIT,  EX  I TSTMT > ; 

NNEOGE< < PROGRAM s . ENTRY,  STMT  L I STs . START ) ; 

SNEDGE I <STMT  L I STs . F I N I SH,  < PROGRAM > . EX I T ) ; 

SETMA I NCALL < <PROGRAMs  CALLNODE) ; 

SETCGRNAME( <PROGRAMs . CALLNODE,  MAKEMAIN) ; 
SETCGREOGE(<PROGRAMs .CALLNODE,  0); 

SETCGRNTRY ( < PROGRAMS . CALLNODE,  < PROGRAMS . ENTRY ) ; 

SETCGREX I T(<PROGRAMs  CALLNODE,  < PROGRAMS . EX I T ) ; 
SETCGRNMFP<< PROGRAMS. CALLNODE,  0); 

SETCGRFPL ( < PROGRAMS . CALLNODE .  0 1 

ACTION  SPECIFICATIONS 

SETACTI 0N( OECLARE,  < PROGRAMS . ENTRY ,  GETOBJSET ( ALPHABET ) ) 

END 

<STMT  LISTS  <STATEMENTs 

SEMANT I CS 

FLOWGRAPH  SPECIFICATIONS 

<STMT  LI STs. LABELDEF  :«  <STATEMENTs . LABELDEF; 

STATEMENTS  .  LABELREF  :*  STMT  LISTs.LABELREF; 

STMT  LI  STs.  START  :«  STATEMENTS  .  START; 

STMT  LISTS. FINISH  :«  < STATEMENTS . F I Nl SH 

ENO 

STMT  LISTdls  :  :  *  <STMT  LIST(2>s  < STATEMENTS 

SEMANTICS 

FLOWGRAPH  SPECIFICATIONS 

<STMT  LIST! 1 ) s . LABELDEF  :*  < STMT  L I ST( 2) s . LABELDEF  ♦ 

STATEMENTS . LABELDEF; 

STMT  LI ST( 2) >. LABELREF  :«  <STMT  L I ST( 1 ) s . LABELREF; 
STATEMENTS . LABELREF  :=  <STMT  L I  ST ( I  I s , LABELREF; 

STMT  LIST!  1  >s  .START  :«  STMT  L I  ST(  2 )  s  .  START; 

STMT  LIST!  1  )s. FINISH  :*  STATEMENTS  .  FI  NISH; 

SNEDGE ( STMT  L I  ST ( 2) s . F 1 Nl SH,  < STATEMENT s . START) 

ENO 

STATEMENT ( 1 ) >  < IDENTIFIERS  < STATEMENT! 2) s 

SEMANTICS 

OBJECT  SPECIFICATIONS 
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SALTRAN  (VERSION: 

02/17/81)  DATE:  81/03/05.  TIME:  11  07  34 

222 

4 

223 

4 

1 NCLUDE <  < I  DENT  1 F I ER> . VALUE ,  LABELS ) 

224 

4 

22S 

4 

FLOWGRAPH  SPECIFICATIONS 

226 

4 

227 

4 

<STATEMENT( 1 ) > . LABELDEF  :=  SETLABEL (< 1  DENT  1 F 1 ER> . VALUE. 

228 

4 

< STATEMENT! 2 )>. ST ART) ; 

229 

4 

<STATEMENT ( 2 ) > . LABELREF  :=  STATEMENT ( 1 ) > . LABELREF ; 

230 

4 

<STATEMENT( 1 >>. START  :*  <STATEMENT ( 2 ) > . START ; 

231 

4 

< STATEMENT ( 1 ) > . F 1 N 1 SH  :*  < STATEMENT ( 2) > . FI N 1 SH 

232 

4 

233 

4 

ACTION  SPECIFICATIONS 

234 

4 

235 

4 

SETACT1 ON(OEF,  STATEMENT ( 1 )>. START ,  t  < I DENTI F I ER> . VALUE 

236 

4 

END 

237 

5 

238 

5 

< STATEMENT >  ::=  " t "  <STMT  LIST>  “ 3“ 

239 

5 

SEMANTICS 

240 

5 

241 

5 

FLOWGRAPH  SPECIFICATIONS 

242 

5 

243 

5 

<STATEMENT>. LABELDEF  :=  <STMT  L 1  ST >. LABELDEF; 

244 

5 

<STMT  LI  ST >  . LABELREF  :*  <STATEMENT> . LABELREF; 

245 

5 

<STATEMENT> .START  : •  <STMT  LlS7>. START; 

246 

5 

<STATEMENT>. FINISH  :*  <STMT  LIST>. FINISH 

247 

5 

END 

248 

6 

249 

6 

<STATEMENT( 1 )>  ::«  <IF  PART>  <STRING>  "THEN"  <STATEMENT ( 2 ) > 

250 

6 

SEMANT I CS 

251 

6 

252 

6 

ATTRIBUTE  SPECIFICATIONS 

253 

6 

254 

6 

CHECKVARI <STRI NG> . VALUE,  <STRI NG> . TOKEN) 

255 

6 

256 

6 

FLOWGRAPH  SPECIFICATIONS 

257 

6 

258 

6 

<STATEMENT(1)>. LABELDEF  :=  <STATEMENT( 2) >. LABELDEF; 

259 

6 

<STATEMENT<2)> .LABELREF  : =  < STATEMENT < 1 > > . LABELREF ; 

260 

6 

<STATEMENT< 1 )> .START  :=  NEWFGNNODE ; 

261 

6 

<STATEMENT< 1 )>. FINISH  :*  C  <STATEMENT( 1 )>. START  1  UNION 

262 

6 

< STATEMENT ( 2) > . FINISH; 

263 

6 

SETFGNTYPC  <STATEMENT ( 1 )>. START,  IFSTMT); 

264 

6 

NNEDGE<<STATEMENT< 1 )> .START,  STATEMENT < 2 ) > . START ) 

265 

6 

266 

6 

ACTION  SPECIFICATIONS 

267 

6 

268 

6 

SETACT 1  ON ( REF,  < STATEMENT C 1 > > . START,  t  <STRI NG> . VALUE  J> 

269 

6 

END 

270 

7 

271 

7 

<STATEMENT>  <EMPTY> 

272 

7 

SEMANTICS 

273 

7 

274 

7 

FLOWGRAPH  SPECIFICATIONS 

275 

7 

276 

7 

< STATEMENT > .LABELDEF  :*  0; 

277 

7 

<STATEMENT>. START  :«  NEWFGNNODE; 

278 

7 

<STATEMENT> . FINISH  :■  I  <STATEMENT> . START  ); 

279 

7 

SETFGNTYPC  <STATEMENT> , START,  EMPTYSTMT) 
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SAL TRAN  (VERSION: 

02/17/81)  DATE:  81/03/05.  TIME:  H  07.35 

280 

7 

ENO 

281 

8 

282 

8 

< STATEMENT >  ::=  "GO"  "TO"  < 1  DENT  t  F I ER> 

263 

a 

SEMANTICS 

284 

8 

285 

8 

ATTRIBUTE  SPECIFICATIONS 

286 

8 

287 

8 

CHECKLABEL ( < 1  DENT I F I ER> . VALUE,  < IDENTIFIER) . TOKEN) 

288 

8 

289 

8 

FLOWGRAPH  SPECIFICATIONS 

290 

8 

291 

8 

<STATEMENT > . LABELOEF  :*  0; 

292 

8 

<STATEMENT> . START  : *  NEWFGNNODE; 

293 

8 

<  ST  ATEMENT  > . F 1 N 1 SH  :■  t  ); 

294 

8 

SETFGNTYP( <STATEMENT> . START,  GOTOSTMT) ; 

295 

8 

NNEDGE ( <STATEMENT> . START, 

296 

8 

GETLABEL ( < 1  DENT 1 F I ER  > . V ALUE ,  <  STATEMENT  > . LABELREF ) 

297 

8 

298 

8 

ACTION  SPECIFICATIONS 

299 

8 

300 

8 

SETACT 1 ON( USE,  STATEMENT >.  START.  t  < 1 DENTI FI ER> . VALUE 

301 

8 

END 

302 

9 

303 

9 

<  ST  ATEMENT  >  : : »  “MOVE"  <01RECT10N>  "ONE"  "SQUARE" 

304 

9 

SEMANT 1 CS 

305 

9 

306 

9 

FLOWGRAPH  SPECIFICATIONS 

307 

9 

308 

9 

<STATEMENT> . LABELDEF  =  0; 

309 

9 

<STATEMENT> . START  :*  NEWFGNNODE; 

310 

9 

<STATEMENT> . FI  NISH  :«  C  <STATEMENT> . START  J; 

31  1 

9 

SETFGNTYP ( <  STATEMENT . START ,  MOVESTMT ) 

312 

9 

END 

313 

10 

314 

10 

<STATEMENT>  ::■  "PRINT"  <5TRING> 

315 

10 

SEMANT 1 CS 

316 

10 

317 

io 

ATTRIBUTE  SPECIFICATIONS 

318 

10 

319 

10 

CHECKVAR( <STR 1 NG> . VALUE,  <STRI NG> . TOKEN) 

320 

10 

321 

10 

FLOWGRAPH  SPECIFICATIONS 

322 

10 

323 

10 

< STATEMENT > . LABELDEF  =0; 

324 

10 

<STATEMENT> . START  :•  NEWFGNNODE; 

325 

10 

<STATEMENT> . FI  NISH  :«  t  <STATEMENT> . START  J; 

326 

10 

SETFGNTYP (< STATEMENT >  START,  PRINTSTMT) 

327 

10 

328 

10 

ACTION  SPECIFICATIONS 

329 

10 

330 

10 

SETACT ION (REF,  <STATEMENT> . START,  t  <STRI NG> . VALUE  J) 

331 

10 

END 

332 

1  1 

333 

1  1 

<01 RfcCT 1 0N>  "LEFT" 

334 

1  1 

SEMANT 1 CS 

335 

1  1 

ENO 

336 

12 

337 

12 

<01 RECT 1 0N»  ::«  "RIGHT" 
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SALTRAN  (VERSION:  02/17/81) 


81 /03/05 . 


07.33. 


338 

12 

SEMANT 1 CS 

339 

12 

END 

340 

13 

341 

13 

OF  PART >  "IF"  "THE"  "TAPE"  "SYMBOL"  "IS" 

342 

13 

SEMANTICS 

343 

13 

END 

344 

14 

343 

14 

<  DECLARATION:*  :.=  "TAPE"  "ALPHABET"  "IS"  <  I  DENT  1  FI  ER> 

346 

14 

SEMANTICS 

347 

14 

348 

14 

OBJECT  SPECIFICATIONS 

349 

14 

350 

14 

1 NCLUDE( < I OENTI FI ER> . VALUE,  ALPHABET) 

351 

14 

END 

352 

15 

333 

15 

<OECLARAT 1  ON (  1  >>  ::  =  <OECLARAT 1 0N{ 2 ) >  " , ”  < 1  DENT  1 F 1 ER> 

354 

15 

SEMANTICS 

355 

15 

356 

15 

OBJECT  SPECIFICATIONS 

337 

15 

356 

15 

1 NCLUDE ( < 1  DENT  1 F I ER> . VALUE ,  ALPHABET ) 

339 

13 

END 

360 

16 

361 

16 

< EMPTY  >  ::«  "NULL" 

362 

16 

SEMANTICS 

363 

16 

END 

364 

17 

365 

17 

366 

17 

END  RULES 

367 

0 

END  language  specifications 

I 
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SALTRAN  (VERSION:  02/17/81)  DATE:  81/03/05. 


TIME:  11.07.37. 
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368  0 

369  0  PROCEDURE  SPECIFICATIONS 

370  0 

371  O  BEGIN 

372  1  END 

373  0 

374  O  END  PROCEDURE  SPECIFICATIONS. 
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SALTRAN  (VERSION:  02/17/81)  DATE:  81/03/05.  TIME:  11.07.37. 


PAOE  1  1 


CROSS  REFERENCE  MAP 


GRAMMAR  SYMBOLS 

RHS 

LINES 

*  < PROGRAM > 

4 

133 

167 

<STMT  L 1 ST> 

3 

137 

167 

193 

204 

<STATEMENT> 

4 

142 

193 

204 

218 

303 

314 

<01 RECT 1 ON> 

1 

147 

303 

333 

337 

< 1 F  PART> 

5 

149 

249 

341 

<  DECLARAT 1 0N> 

4 

151 

167 

345 

353 

<  1  DENT  1 F 1 ER> 

0 

153 

218 

282 

345 

<STRING> 

0 

157 

249 

314 

< EMPTY > 

1 

161 

271 

361 

204 

218 


353 

353 


238 

238 


249  249  271  2( 
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SALTRAN  (VERSION:  02/17/81)  DATE:  81/03/05.  TIME:  11  07  37. 


PAOE  12 


GRAMMAR  ATTRIBUTES 

< PROGRAM? . ENTRY 
< PROGRAM?  EXIT 
‘PROGRAM? . CALLNODE 

<STMT  LI  ST?  . START 
‘STMT  LIST?  FINISH 
‘STMT  LIST?  .  LAP^LREF 
‘STMT  LIST? . LA 5ELt EF 

‘STATEMENT? . START 


‘STATEMENT?  FINISH 

‘STATEMENT? . LABELREF 
‘STATEMENT?  LABELDEF 


‘IDENTIFIER? . VALUE 
‘IDENTIFIER? . TOKEN 

‘STRING?  VALUE 
‘STRING? . TOKEN 


RESERVED  TOKENS 


GO  TO  MOVE 

LEFT  RIGHT  IF 

IS  ALPHABET 


LINES 


SYNTHESIZED 

134 

172 

176 

SYNTHESIZED 

1  34 

1  73 

177 

SYNTHESIZED 

1  35 

1  74 

1  80 

SYNTHESIZED 

138 

1  76 

200 

SYNTHESIZED 

1  39 

1  79 

201 

INHERITED 

140 

175 

199 

SYNTHESIZED 

140 

1  75 

198 

SYNTHESIZED 

143 

200 

215 

263 

264 

264 

300 

309 

310 

SYNTHES1 ZEO 

144 

310 

201 

325 

214 

INHERI TED 

145 

1  99 

212 

SYNTHESIZED 

145 

323 

198 

210 

SYNTHESIZED 

154 

223 

227 

SYNTHESIZED 

155 

267 

SYNTHESIZED 

156 

254 

268 

SYNTHESIZED 

159 

254 

319 

t 

J 

ONE 

SQUARE 

THE 

TAPE 

NULL 

178 

183 

190 

179 

184 

181 

182 

183 

184 

185 

1  86 

213 

213 

245 

214 

215 

246 

21  1 

21  1 

212 

244 

209 

209 

243 

228 

230 

230 

235 

245 

260 

26 

268 

277 

278 

279 

292 

294 

29 

31  1 

324 

325 

326 

330 

231 

231 

246 

261 

262 

278 

29 

229 

229 

244 

259 

259 

296 

227 

243 

258 

258 

276 

291 

30 

235 

287 

296 

300 

350 

358 

319 

330 

THEN 

PRINT 

SYMBOL 
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SALTRAN  (VERSION:  02/17/81)  DATE:  81/03/05.  TIME  11 . 07  37 


tiiiiiisiimixoMimi 


PROGRAM  STATISTICS 


SYMBOLS 

SPECIAL  SALTRAN  SYMBOLS 
GRAMMAR/ATTRIBUTE  SYMBOLS 
OTHER  SYMBOLS 


109  (TOTAL  SYMBOLS) 
63 
24 
22 


HASH I NG 

NUMBER  OF  CALLS 
NUMBER  OF  PROBES 
FAX  MUM  PROBE 
AVERAGE  PROBE 

PRODUCT  I  ON -TABLE  /  PRODUCTION-LIST 
PRODUCT  I  ON - TABLE 
PRODUCT  I ON- LI  ST 

SYNTAX  RULES 

SEMANTIC  RULES 

OBJECT-CLASS  RULES 
ATTRIBUTE  RULES 
FLOWGRAPH  RULES 
ACTION  RULES 
OTHER  RULES 

TABLES  (PERCENT  FULL) 

SYMBOL  TABLE 
CROSS-REFERENCE  TABLE 

TOTAL  PRODUCTION  SYMBOLS  * 

TOTAL  GRAMMAR  ATTRIBUTES  = 

TOTAL  RESERVED  TOKENS  * 

TOTAL  PROGRAM  LINES  * 


50  (TOTAL  ENTRIES) 
16 
34 

16  (TOTAL) 

67  (TOTAL) 

3 

3 

56 

5 

0 


MAXIMUM  RIGHT-HANO-SIDE  HAS  5  TERMINALS  AND  NONTERMINALS 


TRANSLATION  TIME  =  4.06  SECONDS  *>  92.07  LINES/SECOND. 
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D.2  Sample  TURINGOL  Program 


TREE  BUILDING  ANALYZER  VERS  I 0N  =  05/ 1 3/80 
TIME3  11.28.04.  DATE3  81/03/05. 

I 

1  TAPE  ALPHABET  IS  BLANK,  El N,  ZERO.  POINT; 

12  PRINT  "POINT"; 

15  GO  TO  CARRY; 

19  TEST:  IF  THE  TAPE  SYMBOL  IS  “EIN"  THEN 

28  [PRINT  “ZERO";  CARRY:  MOVE  LEFT  ONE  SQUARE;  QO  TO  TEST1 ; 

44  PRINT  "EIN”; 

47  REALIGN:  MOVE  RIGHT  ONE  SQUARE; 

54  IF  THE  TAPE  SYMBOL  IS  “ZERO"  THEN  GO  TO  REALIGN. 

END  OF  ANALYSIS  COMPILE  TIME=  .7  SECONDS 
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D.3  Output  Report  for  Sample  Program 


STATISTICS 


ALLOCATED  MEMORY: 


BASIC  UNIT 

NO.  UNITS 

WORDS/UNIT 

TOTAL  WORDS 

SYMBOL  TABLE 

SYMBOL 

32 

2(1) 

64 

ATTRIBUTE  TABLE 

ENTRY 

3 

1  (2) 

3 

rv.RSE  TREE 

NODE 

47 

2 

94 

DEPENDENCY  GRAPH 

NODE 

155 

2 

310 

DEPENDENCY  GRAPH 

EDGE 

80 

1 

80 

FLOW  GRAPH 

NODE 

12 

4  (3) 

48 

EXPRESSION  TREE 

NODE 

0 

4  (3) 

0 

CALL  GRAPH 

NODE 

1 

2 

2 

PRODUCTION  TABLE 

NUMBER 

20 

1 

20 

SET  POOL 

SET 

47 

10 

470 

TOTAL  WORDS 

*  1091 

(1)  INCLUDES  1  WORD ( S ) /STRING 

(2)  INCLUDES  t  ATTR I BUTE ( S ) /ENTRY 

(3)  INCLUDES  4  ACT  I  ONI S ) /NODE 


PROGRAM  SIZE: 


NUMBER 

OF 

PARSE  TREE  NODES 

47 

NUMBER 

OF 

PROGRAM 

LINES 

9 

=  > 

9.22 

NODES/LINE 

NUMBER 

OF 

PROGRAM 

TOKENS 

69 

=  > 

0.72 

NODES/ TOKEN 

TIMING  (SECONDS): 
PARSING  PHASE 
ATTRIBUTE  ANALYSIS 
I  0.  18 
(  0.09 

(  0.31 

(  0.94 


0.64  =  >  13.99  LINES/SEC 

PHASE  1.12  *>  8.04  LINES/SEC 

FOR  READING  TABLES  AND  INITIALIZING  NODULES) 
FOR  DEP.  GRAPH  BUILDING  ) 

FOR  DEP.  GRAPH  EVALUATION  ) 

FOR  DUMPING  TABLES  AND  STATS  ) 


TOTAL  SAM  ANALYSIS  TIME  1.76  *>  9.10  LINES/SEC 

*>  36.89  TOKENS/SEC 
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D.4  Tables  File  for  Sample  Program 


4  WRITE  OUT  ACTION  NAMES 
DECLARE 
REF 
USE 
DEF 

10  WRITE  OUT  FLOWGRAPH  NODE-TYPES 
BASE 
CONCAT 
STRUCT 
ENTRYSTMT 
EX I TSTMT 
1FST.it 
EMP TYS-MT 
GOTOC'iHT 
MOVESTMT 
PRINTSTMT 

32  BEGINNING  OF  SYMBOL  TABLE 
4  O  .EOF 

1  O  ; 

1  O  . 

1  0  : 

1  0  C 

1  0  1 

4  0  THEN 

2  0  GO 

2  O  TO 

4  0  MOVE 

3  0  ONE 

6  O  SQUARE 

5  0  PRINT 

4  O  LEFT 

5  0  RIGHT 

2  OIF 

3  0  THE 

4  O  TAPE 

6  O  SYMBOL 

2  0  IS 

8  0  ALPHABET 

1  0  . 

4  0  NULL 

5  O  BLANK 

3  0  El N 

4  O  ZERO 

5  0  POINT 

5  3  CARRY 

4  2  TEST 

7  1  REALIGN 

0  0 

8  0  TURINGOL 

1  1 

32  0  2  1  CALLGRAPH  OVERHEAD  FOR  CALL -NODE  1 

0 

0  END  OF  USE  TABLE  FOR  CALL -NODE  1 

2  4  0 

1  12 

0 

4  24  25  26  27 

0 
0 
0 

12  10  0 

1  1  1 


. 

1 

2 

0 

1 

27 

0 

; 

0 

t 

i 

11 

8 

O 

1 

9 

i 

j  1 

12 

Y 

i  0 

f 

i  ° 

'  o 

28 

9 

9 

0 

1 

8 

2 

10 

1  1 

O 

■ 

0 

0 

1  ji 

1 

28 

8 

8 

0 

1 

7 

1 

9 

0 

0 

! 

1 

29 

i 

0 

7 

6 

0 

2 

6 

10 

1 

8 

'i 

0 

! 

1 

23 

; 

o 

1 

29 

10 

10 

0 

1 

9 

1 

7 

0 

1 

26 

0 

0 

, 

6 

10 

0 

!  1 

S 

1 

7 

0 

1 

23 

0 

o 

■  5 

9 

0 

■;  ■:  1 

3 

,  i  2 

4 

6 

;  1  0 

:  I  0 

f’ f  0 

•S  i 

30 

:W  3 

6 

0 

m  2 

1 

4 

m  1 

5 

1  “ 

26 

BP  o 

■ 

m 

6 

0 

OOOUOO-O  —  0-00 


Appendix  D 


81 


1  5 

1  3 

30 

5  0 

3 


END  OF  FLOWGRAPH  FOR  CALL -NODE  1 
END  OF  EXPRESSION-TREE  FOR  CALL-NODE  1 


D.5  User-Readable  Report  of  Tables  File 


LISTING  OF  CALLGRAPH  INFORMATION:  MAINCALL=  TURINGOL 
NODE  EDGES 

TURINGOL 

NODE  NUM  PARAM  PARAM  MODES 


TURINGOL 


0 
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DUMP  OF  PARTIAL  FLOWGRAPH  FOR  SUBPROGRAM  TUR1NGOL  : 

ENTRY  NODE  =  2,  EXIT  NODE  *  1 
. . . USE-TABLE  . . 


FLOW-GRAPH 


2 


12 


1  1 


9 


a 


7 


10 


6 


DESCRPT=ENTRYSTMT 
SONS  =  1 2 

PARENTS* 

DECLARE  = 


EXP-TREE* 


REF  =  < EMPTY > 

USE  =  < EMPTY* 

DEF  =  < EMPTY > 

DESCRPT  * PR I NTSTMT  EXP-TREE* 

SONS  *  1  1 

PARENTS*  2 

DECLARE  *  < EMPTY > 

REF 

USE  *  < EMPTY > 

DEF  *  < EMPTY* 

DESCRPT =GOTOSTMT  EXP-TREE* 

SONS  *  9 

PARENTS*  1 2 

DECLARE  =  < EMPTY* 

REF  *  < EMPTY* 

USE  * 

DEF  *  < EMPTY* 

DESCRPT =MOVESTMT  EXP -TREE* 

SONS  *  8 

PARENTS*  10  11 

DECLARE  *  < EMPTY* 

REF  =  < EMPTY* 

USE  *  < EMPTY* 

DEF  * 

DESCRPT *30T0STMT  EXP-TREE* 

SONS  *  7 

PARENTS*  9 

DECLARE 
REF 
USE 
OEF 

DESCRPT* I FSTMT 
SONS  «  6 

PARENTS*  8 

DECLARE 
REF 
USE 

DEF  ■ 

DESCRPT* PR  I NTSTMT 
SONS  *  9 


< EMPTY* 
<EMPTY> 


< EMPTY* 

EXP- 

10 


TREE* 


< EMPTY* 


*  < EMPTY* 


EXP -TREE- 


PARENTS* 

OECLARE 
REF 
USE 
OEF 

DESCRPT*PR| NTSTMT 
SONS  *  5 

PARENTS- _ 7 


*  < EMPTY* 


<EMPTY> 

< EMPTY* 

EXP- 


TREE* 


0 


BLANK 

ZERO 


0 


POINT 


0 


CARRY 

0 


CARRY 

0 

TEST 

0 

El  N 
TEST 

0 

ZERO 

0 


■  *' 


El  N 
POINT 
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DECLARE  *  < EMPTY > 

REF  =  E I N 

USE  =  <EMPTY> 

DEF  *  < EMPTY > 

DESCRPT =MCVESTMT  EXP-TREE*  0 

SONS  =  3 

6 

<EMPTY> 

< EMPTY* 

< EMPTY > 

REALIGN. 
EXP-TREE*  0 
4 


*  < EMPTY* 

■  < EMPTY* 

»  < EMPTY* 

EXP -TREE*  0 


PARENTS*  4 

DECLARE  = 

REF  = 

USE  * 

DEF  * 

DESCRPT* I FSTMT 
SONS  *  1 

FARENTS*  S 

DECLARE 
REF 
USE 
DEF 

DESCRPT  *0OTOSTMT 
SONS  =  5 

PARENTS*  3 

DECLARE  *  < EMPTY* 

REF  =  < EMPTY* 

USE  ■ 

DEF  =  < EMPTY* 

DESCRPT =EX I TSTMT  EXP-TREE*  0 

SONS  = 

PARENTS*  3 

DECLARE 
REF 
USE 
DEF 


ZERO 


REALIGN 


< EMPTY* 
<EMPTY> 
< EMPTY* 
<EMPTY> 


EXPRESS  I ON- TREE  INFORMATION 


SET -POOL  IS  2  PERCENT  FULL 
0.26  SECONDS 


